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Abstract 

This  thesis  presents  SodaBot ,  a  general-purpose  software  agent  user-environment  and 
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We  also  present  a  new  language  for  programming  the  basic  software  agent  whose 
primitives  are  designed  around  human-level  descriptions  of  agent  activity.  Via  this 
programming  language,  users  can  easily  implement  a  wide-range  of  typical  software 
agent  applications,  e.g.  personal  on-line  assistants  and  meeting  scheduling  agents. 
The  SodaBot  system  has  been  implemented  and  tested,  and  its  description  comprises 
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Chapter  1 
Introduction 


This  thesis  is  about  creating  software  agents.  We  argue  that  software  agents  should 
be  written  using  a  vocabulary  not  provided  by  traditional  programming  languages  — 
it  should  be  possible  to  create  agents  solely  by  specifying  their  abstract  behavior. 

Motivated  by  this  position,  we  introduce  SodaBot ,  a  general-purpose  software 
agent  user-environment  and  construction  system.  Its  primary  component  is  the  basic 
software  agent  —  a  computational  framework  for  building  agents  which  is  essentially 
an  agent  operating  system.  We  also  present  a  new  language  for  programming  the  basic 
software  agent  whose  primitives  are  designed  around  human-level  descriptions  of  agent 
activity.  Via  this  programming  language,  users  can  easily  implement  a  wide-range 
of  typical  software  agent  applications ,  e.g.  personal  on-line  assistants  and  meeting 
scheduling  agents.  The  SodaBot  system  has  been  implemented  and  tested,  and  its 
description  comprises  the  bulk  of  this  thesis. 

This  introduction  is  divided  into  the  following  sections: 

(1.1)  What  is  a  software  agent  in  the  first  place? 

(1.2)  What  research  problems  motivated  this  work? 

(1.3)  What  is  the  SodaBot  system  and  how  does  it  solve  these  problems? 

(1.4)  A  reader’s  guide  to  the  remainder  of  the  thesis 
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1.1  Software  Agent? 

The  beginning  is  always  a  good  place  to  start,  so  what  exactly  is  a  software  agent? 
The  answer  depends  on  whom  you  ask  and  can  vary  quite  widely.  (See  chapter  5 
for  some  typical  responses.)  For  the  purposes  of  this  thesis,  however,  we  will  focus 
exclusively  on  creating  two  specific  types  of  software  agents:  (1)  personal  assistants 
and  (2)  application  agents}  First,  we  examine  some  typical  high-level  characteristics 
these  two  groups  have  in  common,  and  then -we  look  at  several  representative  agents 
from  each. 

Agents  in  the  Abstract 

Agents  are  autonomous  and  temporally  continuous.2  Agents  can  act  in  behalf  of  par¬ 
ticular  people,  i.e.  they  can  take  actions  which  appropriately  represent  the  interests  of 
others;  therefore,  agents  must  also  be  robust  and  capable  of  securely  handling  private 
information.  Agents  tend  to  be  highly  interactive  —  they  spend  much  of  their  time 
communicating  with  other  agents  and  human  beings.  Agents  are  active  participants 
in  their  computational  universe,  i.e.,  they  react  to  and  cause  changes  in  overall  system 
state. 

Agents  in  the  Concrete 

Agents  are  practical  and  helpful.  We  are  particularly  interested  in  the  construction  of 
software  agents  that  automate  simple  on-line,  repetitive  and  time-consuming  tasks. 
Although  we  are  interested  in  using  software'  agents  as  a  “testbed”  for  other  areas  in 
core  AI  ([Etzioni,  1993]),  we  must  keep  in  mind  that  “one  of  the  most  challenging 
aspects  of  agent  design  is  to  define  specific  tasks  that  are  both  feasible  using  current 
technology  and  are  truly  useful...” ([Kautz  et  al .,  1994]) 

Although,  much  of  our  discussion  applies  to  other  types  of  agents  as  well. 

2In  this  particular  sense,  they  are  similar  to  Unix  daemon  processes,  but  agents  are  generally 
associated  with  particular  people  or  high-level  applications. 
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We  focus  here  on  building  the  following  two  types  of  software  agents: 

1.  personal  on-line  assistants:  These  agents  generally  belong  to  particular  people 
and  act  like  simple  electronic  secretaries.  They  do  things  such  as: 

a)  automatically  respond  to  requests  to  schedule  meetings  by  consulting 
their  owner’s  private  schedule; 

b)  keep  track  of  their  owner’s  whereabouts  and  provide  this  information  on 
request; 

c)  contact  their  owner  appropriately  based  on  her  location,  e.g.  via  display¬ 
ing  a  window  on  her  workstation,  sending  a  fax,  or  even  making  a  phone 
call  (SodaBot  can’t  telephone  yet,  but  see  [Kautz  et  al,  1994] .) 

d)  filter  and  sort  incoming  e-mail  and  faxes  based  on  their  owner’s  prefer¬ 
ences  (which  may  be  provided  explicitly  or  someday  learned  from  ob¬ 
served  behavior.). 

2.  application  agents:  These  agents  coordinate  the  transfer  and  processing  of  in¬ 
formation  among  people  and  other  agents.  Application  agents  include: 

a)  Time  schedulers  which  schedule  group  or  individual  meetings  among 
a  set  of  people  by  negotiating  among  their  personal  agents 
to  maximize  some  “convenience”  measure. [Maes  and  Kozierok,  1993, 
Dent  et  al. ,  1992,  Kautz  et  al.,  1994]. 

b)  Text  processing  systems  which  allow  complex  processing  of  documents 
involving  many  people  at  different  sites. 

c)  Receptionist  agents  which  accept  requests  and  determine  their  appropri¬ 
ate  destinations  by  interacting  with  other  agents  (and  perhaps  people  as 
well).3 

It  is  important  to  remember  that  software  agents  are  simply  computer  programs, 
like  expert  systems,  text  editors,  etc.  Sometimes,  especially  given  the  anthropomor- 


3This  is  work  in  progress  with  Randy  Davis  and  Howie  Shrobe. 
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phic  autonomy  of  agents,  it  is  easy  to  lose  track  of  this  and  disconnect  expectations 
from  reality.  However,  one  must  keep  in  mind  that  what  other  programs  cannot  yet 
do,  e.g.  converse  in  English,  agents  cannot  yet  do  either.  Nevertheless,  throughout 
this  thesis,  we  will  treat  software  agents  as  a  unique  class  of  computational  entities 
—  agents  are  paradigmatically  distinct  from  other  types  of  computer  software.  This 
outlook  will  direct  how  we  intend  for  agents  to  be  used  and  what  types  of  tasks  we 
expect  agents  to  perform. 


1.2  The  Problem 

Much  of  the  work  done  in  the  area  of  software  agents  can  be  placed  into  one  of 
two  categories:  (1)  highly  theoretical  treatment  of  agents’  intentions  and  capabilities 
([Shoham,  1993,  Doyle  et  al. ,  1991,Etzioni  et  al.,  1992a]);  (2)  applied  construction  of 
specific  agents  ([Etzioni  and  Segal,  1992,  Maes  and  Kozierok,  1990,  Vere  and  Bick- 
more,  1990,  Dent  et  al. ,  1992,  Kautz  et  al .,  1993]).  However,  determining  for  what 
(and  if)  software  agents  are  actually  useful  requires  building  many  of  them,  and  the 
agent  construction  process  poses  difficult  technical  challenges. 

It  is  generally  straightforward  to  specify  an  agent’s  abstract  behavior,  e.g.  “I  want 
the  agent  to  ask  some  user  a  question;  it  should  remember  her  response  in  case  the 
same  question  comes  up  again.  Then,  it  should  process  the  response  by  calling  my 
preexisting  C-language  application  on  it  and  communicate  the  result  to  some  other 
agent.”  However,  traditional  programming  languages  offer  no  primitive-level  support 
for  the  typical  kinds  of  high-level  “online  activities”  in  which  agents  engage,  e.g. 
graphically  obtaining  structured,  typed  information  from  a  user  or  communicating 
reliably  with  other  agents. 

Building  agents  generally  involves  a  multi-layered  approach.  First,  it  requires  a 
great  deal  of  specific  “system-hacking,”  e.g.,  of  esoteric  system  software,  networking 
protocols,  windowing  systems.  (See  [Kautz  et  al. ,  1994]  for  a  discussion  of  the  diffi- 
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culties  involved  in  handling  the  most  basic  of  agent  functions,  e.g.,  reading  e-mail  reli¬ 
ably.)  Second,  agent  construction  frequently  involves  mid-level  computational  issues, 
e.g.  having  agents  handle  several  events  simultaneously,  provide  reliable  transactions, 
or  handle  errors  automatically.  Finally,  agents  (usually)  do  something  with  their  com¬ 
putational  foundation.  For  example,  researchers  in  artificial  intelligence  may  want  to 
implement  agent-based  schedulers  or  knowledge  representation  systems. 

Each  of  these  layers  can  require  a  substantial  amount  of  independent  implementa¬ 
tion  and  debugging  time.  So  much  so,  in  fact,  that  very  few  software  agents  have  yet 
been  built.  And  although  the  need  to  simplify  agent  construction  is  obvious,  there 
are  as  yet  few  systems  designed  to  assist  the  agent  creator. 

Additionally,  it  can  be  difficult  to  distribute  new  agents,  i.e.,  to  introduce  them 
to  the  world  and  let  other  people  use  them.  Agents  tend  to  be  site-specific  in  intri¬ 
cate  ways  and  disconnecting  them  from  their  local  dependencies  can  be  technically 
involved.  Furthermore,  an  agent  which  has  been  “disconnected”  from  its  birth-site 
can  also  be  quite  challenging  to  install. 

Finally,  in  particular  with  software  that  handles  sensitive  information  and  may 
even  represent  the  user  in  interactions  with  other  people,  a  person  needs  an  enormous 
amount  of  confidence  that  the  software  will  operate  correctly.  For  example,  who  is 
likely  to  ftp  and  install  a  random  program  capable  of  autonomously  sending  e-mail 
in  their  name? 

Thus,  we  see  three  problems  with  building  software  agents  today: 

1.  They  are  technically  challenging  to  write  in  traditional  programming  languages 
and  operating  systems. 

2.  They  are  difficult  to  distribute  because  they  may  have  site-specific  dependencies; 
for  the  same  reason,  they  can  be  difficult  to  install. 

3.  People  may  be  uncomfortable  with  the  amount  of  responsibility  given  to  an 
unknown  (and  possibly  buggy)  agent. 
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1.3  Towards  a  solution 

This  thesis  presents  SodaBot,  a  general-purpose  software  agent  user-environment  and 
construction  system.  In  this  section,  we  introduce  the  SodaBot  system  and  outline 
how  it  addresses  the  three  aforementioned  problems. 

The  four  primary  components  of  SodaBot  discussed  below  are: 

(1.3.1)  The  basic  software  agent 

(1.3.1)  The  graphical  user  interface 

(1.3.2)  The  SodaBot  agent  programming  language 

(1.3.3)  Automatic  distribution  of  application  agents 

1.3.1  The  SodaBot  Software  Agent  Paradigm 

In  SodaBot,  each  user  (or  owner)  is  given  a  personal  basic  software  agent  (BSA)  which 
typically  runs  in  the  background  on  her  home  workstation.4  The  BSA  is  an  agent 
operating  system  —  think  of  it  as  the  “Unix  of  the  software  agent  world.”  By  this, 
we  mean  that  it  is  a  generic  (in  the  sense  of  universal)  computational  framework  for 
implementing  and  running  specific  agent  applications.  The  BSA  is  programmed  in 
the  SodaBot  agent  programming  language  (SodaBotL).5  As  a  quick  sanity  check,  see 
if  the  following  (rough)  analogy  makes  sense: 

SodaBotL  is  to  SodaBot  the  way  C++  is  to  Unix. 

A  BSA  runs  SodaBotL  programs  provided  both  by  its  owner  and  by  other  people. 
It  implements  a  time-sharing  scheduling  algorithm,  so  only  one  BSA  needs  to  be 
running  to  simultaneously  execute  several  agent  applications  for  a  particular  user  — 
see  figure  1-1.  The  BSA  runs  an  agent  until  it  needs  to  wait  for  something,  e.g. 

4The  BSA  can  alternately  be  configured  in  several  other  ways.  See  section  2.1 
5  Pronounced  “Soda-Bottle.” 
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user-input  or  communication  from  another  agent.  At  this  point,  the  BSA  can  put 
this  agent  to  sleep  and  schedule  another  one  in  its  place. 

The  user  and  her  BSA  interact  through  the  SodaBot  graphical  user  interface 
(GUI).  Figure  1-2  shows  the  GUI  of  a  BSA  running  on  a  Sun  Sparc  workstation. 
In  this  setup,  the  GUI  occupies  one  of  several  virtual  screens  available  to  the  user. 
(However,  it  can  open  windows  on  whichever  virtual  screen  the  user  has  active.)  The 
central  window  in  the  display  contains  the  BSA’s  main  interface;  it  allows  the  user  to 
monitor  and  control  the  BSA’s  activity  —  including  reviewing  and  limiting  its  access 
to  system  resources.  The  top  of  the  screen  displays  the  SodaBot  agent  editor  which 
allows  the  user  to  create,  compile,  and  install  agent  applications.  The  editor  can  also 
be  used  to  inspect  incoming  agent  applications  provided  by  other  people.  Finally, 
the  bottom  of  the  screen  contains  several  windows  opened  by  various  software  agents 
running  on  the  BSA. 

The  GUI  was  designed  to  provide  the  user  with  a  sense  of  control  over  her  BSA; 
she  can  enable  or  disable  various  capabilities  —  e.g.  having  it  modifying  her  e-mail 
file  —  depending  on  her  confidence  in  it  (or  lack  thereof).  [Kautz  et  al,  1994]  makes 
clear  that  people  are  uncomfortable  delegating  absolute  authority  to  software  agents. 
By  giving  the  user  a  large  degree  of  control  over  agent  activity,  we  hope  to  help 
assuage  fears  that  the  BSA  will  do  something  inappropriate  or  destructive. 

The  BSA  has  a  novel  architecture  which  allows  it  to  perform  a  variety  of  com¬ 
plex  agent-oriented  tasks  such  as:  reliably  handle  e-mail;  graphically  and  textually 
interact  with  users;  handle  multiple  concurrent  events;  interact  in  site-specific  ways 
with  its  computational  environment  (e.g.  run  other  system  software,  speak  with  a 
fax  machine,  etc.).6  Typically,  an  individual  software  agent  application  must  perform 
a  number  of  these  activities.  However,  robustly  implementing  such  tasks  typically 
requires  a  large  programming  effort  and  much  esoteric  system  knowledge.  Therefore, 

6 Several  other  features  of  the  BSA  will  only  make  sense  after  we  have  introduced  more  of  the 
system  and  are  therefore  discussed  below. 
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Figure  1-1:  The  Basic  Software  Agent 


Figure  1-2:  The  BSA  running  on  a  Unix  workstation 
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the  BSA  comes  with  them  “built-in,”  and  the  SodaBot  agent  programming  language 
offers  high-level  primitives  through  which  they  can  be  accessed. 

What  does  the  BSA  buy  us?  It  essentially  disconnects  agent  programs  from  the 
specific  computational  environment  in  which  they  run.  They  no  longer  need  to  be 
“hard-coded”  with  specific  parameters  for  particular  activities,  e.g.  they  don’t  require 
special  knowledge  of  a  host’s  mailer  set-up.  The  problem  of  configuring  many  software 
agents  is  reduced  to  the  problem  of  configuring  a  single  agent,  the  BSA.  Thus,  for 
example,  SodaBot  agent  programs  written  at  MIT  could  be  run  without  modification 
on  BSAs  at  AT&T  Bell  Labs.7  Furthermore,  when  a  Macintosh  or  PC-based  BSA 
is  created,  agent  programs  running  on  Unix-based  BSAs  can  be  run  directly  on  Mac 
and  PC-based  BSAs.8  Also,  the  BSA  takes  advantage  of  empirical  knowledge  we 
have  gained  installing  various  software  agents  on  several  Unix  configurations,  and  it 
attempts  to  automate  its  own  installation. 

The  BSA  paradigm  also  assists  in  the  development  of  user  confidence  in  agent 
applications,  because  the  BSA  provides  the  only  interface  to  critical  system  com¬ 
ponents.  For  example,  if  the  BSA  knows  how  to  provide  event  time-outs  or  how  to 
communicate  correctly  over  TCP/IP,  application  agents  running  on  the  BSA  do  also.9 

Finally,  there  is  a  simple  computational  efficiency  gain  by  having  only  a  single  BSA 
image  in  memory  rather  than  several  independent  agent  programs.  The  atomicity  of 
agent  execution  enforced  by  the  time-sharing  model  can  also  simplify  interaction 
among  several  separate  agent  applications. 

7In  fact,  BSAs  automatically  distribute  sections  of  new  agent  programs.  Therefore,  this  property 
is  essential  for  providing  guarantees  of  correct  behavior. 

8This  assumes,  of  course,  that  they  are  not  Unix  dependent  because  a  non-portable  SodaBotL 
System  call.  However,  even  in  this  case,  an  agent  can  be  divided  into  various  sections,  some  of  which 
run  in  Mac  and  PC-based  environments  and  others  which  run  exclusively  in  Unix  environments.  See 
section  3.1 

9Of  course,  simply  knowing  how  to  use  something  doesn’t  provide  any  guarantee  of  the  appro¬ 
priateness  of  a  particular  use.  We  discuss  this  topic  in  greater  depth  in  section  3.4. 
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1.3.2  The  Software  Agent  Programming  Language 

The  SodaBot  agent  programming  language  (SodaBotL)  offers  high-level  primitives 
and  control-structures  designed  around  human-level  descriptions  of  agent  activity. 
SodaBotL  abstracts  out  the  low-level  details  of  agent  implementation.  In  a  typical 
Unix  environment,  for  example,  SodaBotL  frees  agent  creators  from  the  bother  of 
dealing  with  system  calls,  mail  servers,  sockets,  and  X-windows.  It  is  therefore  much 
easier  to  have  an  agent: 

1.  Ask  a  question: 

Ask  {prompt  “Time”}  “When  are  you  returning?”; 

2.  Display  a  message: 

Display  { prompt  “Read  it?”;  Choices(yes,  no)}  “Mail  from  $sender:  $subject”; 

3.  Contact  another  agent: 

Contact  Agent  <Receptionist;  querier>  {users:  $inferred} 

“Do  you  know  who  in  the  AI  Lab  is  responsible  for  Stopic?” 

4.  Handle  time: 

Wait  until  Tuesday  before  $date:  { 

Display  “Reminder,  you  have  an  appointment  with  S person  on  $date”;} 

The  SodaBot  language  design  focuses  specifically  on  building  two  kinds  of  software 
agents:  (1)  personal  assistants  -  Each  user  has  a  private  SodaBot  basic  agent  which 
she  can  customize  to  act  as  a  simple  electronic  secretary.  A  user  can  program  her  agent 
in  SodaBot  to  do  things  such  as:  filter  incoming  e-mail;  notify  her  about  particular 
events  (e.g.  someone  has  returned  to  his  office);  or  automatically  handle  incoming 
requests.  Users  and  other  agents  can  also  contact  someone’s  personal  assistant  much 
in  the  same  spirit  one  would  a  human  secretary.10  (2)  application  agents  -  Users  can 
create  agents  that  specifically  provide  various  services.  Application  agents  are  also 

10 We  have  also  been  considering  the  development  of  personal  assistants  for  mobile  robots  which 
would  provide  on-line  remote  access  to  them. 
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Agent{Pollster}: 

Get  Response  {prompt  aAnd  what’s  your  opinion?”; 
timeout  in  10  minutes} 
SmessageJbody; 

Reply  with  Sresponse; 


Figure  1-3:  A  simple  agent  for  gathering  opinions. 


Pollster  Yessage  from  Gary  Borcharctt 


The  following  is  the  tentative  schedule 
for  this  year's  ai  Seminars.  We  are  soli 
before  v«  Issue  Invitations.  Note:  theij 
particularly  strong  interest  this  year 
researchers  in  Software  Agents: 

Alan  Turing 
John  von  Neumann 


Jiao'  vine  t  year  ofialea ? 


[How  about  Kurt  Godel?| 


<>  Done/ Mai  1 


Figure  1-4:  The  Pollster  window. 


called  SodaBots.  For  example,  figure  1-3  has  a  simple  Pollster  agent.  This  agent 
allows  us  to  quickly  solicit  opinions  from  a  group  of  people  by  directing  a  Pollster 
message  to  their  personal  agents. 


1.3.3  Automatic  Agent  Distribution 

A  SodaBot  environment  is  composed  of  a  society  of  basic  software  agents  which  are 
connected  via  the  Internet  (and/or  a  local  area  network).  Within  an  environment, 
new  application  agents  are  automatically  distributed  —  as  SodaBotL  programs  — 
among  its  constituent  BSAs.  For  example,  suppose  Robyn  creates  a  group  meeting 
scheduler.  When  she  schedules  the  first  meeting,  the  basic  software  agents  owned 
by  the  people  in  her  group  will  automatically  request  their  required  sections  of  this 
application  agent  from  her  BSA.  Note  that  SodaBot  does  not  enforce  a  client/server 
model  of  agent  interaction.  Sections  of  an  agent’s  program  are  distributed  as  the  need 
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arises,  and  the  “server”  role  in  an  agent  might  dynamically  rotate  among  the  basic 
agents  or  might  not  exist  at  all. 

Additionally,  SodaBotL  allows  for  context-dependent  interpretation  of  its  prim¬ 
itives  based  on  their  run-time  environment.  Primitives  are  requests  to  perform  an 
action  that  do  not  actually  specify  how  the  action  should  be  done.11  For  example,  a 
request  in  an  agent’s  program  to  display  a  message  can  be  satisfied  by  one  (or  more) 
of  the  following,  depending  on  the  owner’s  location:  (1)  put  up  a  window  on  the 
user’s  display;  (2)  e-mail  the  message  to  the  user;  or  (3)  fax  it  to  her,  etc. 

Finally,  because  SodaBotL  agent  programs  can  be  much  shorter  than  their  coun¬ 
terparts  written  in  other  systems,  e.g.  C  on  a  Unix  platform,  they  are  that  much 
easier  to  debug  and  inspect  for  security  threats.  For  example,  while  it  may  not  be 
possible  for  a  user  to  peruse  a  random  agent  program  she  ftp’ed  from  somewhere 
on  the  Internet,  it  is  quite  feasible  that  she  can  inspect  in  detail  a  SodaBotL  agent 
received  by  her  BSA.  (Security  issues  are  discussed  in  section  3.4) 

1.4  Reader’s  Guide 

The  remainder  of  this  thesis  discusses  the  SodaBot  system  and  how  it  simplifies  the 
construction  of  software  agents.  We  do  not  propose  that  SodaBot  is  a  universal  agent 
construction  tool  or  that  its  level  of  support  is  sufficient  for  all  or  even  many  applica¬ 
tions.  However,  central  to  the  design  of  SodaBot  is  that  all  of  its  main  components  are 
separate,  replaceable  modules.  If  some  capability  is  not  provided  or  if  some  feature  is 
inappropriate  for  a  particular  site,  that  part  can  be  added  or  replaced  while  treating 
the  rest  of  the  system  as  a  black-box  abstraction.  Also,  particular  SodaBot  modules 
can  be  incorporated  into  other  programs.  For  example,  an  application  which  needs 

n[Kautz  et  al,  1994]  describes  this  as  “intension”  vs.  “extension,”  (i.e.  “connotation”  vs.  “deno¬ 
tation”).  It  is  not  clear  this  terminology  (drawn  from  linguistics)  accurately  describes  the  intended 
phenomenon.  At  least  with  respect  to  SodaBot,  context-dependency  is  simply  with  respect  to  the 
medium  for  conveying  information;  the  information  explicitly  must  be  made  available,  but  the  BSA 
may  select  precisely  how. 
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to  receive  and  filter  e-mail  can  use  just  these  parts  of  the  SodaBot  system.  Finally, 
SodaBot  can  be  used  to  get  fast,  working  prototypes  of  software  agents,  even  if  it  is 
intended  that  the  final  application  be  completely  written,  say,  in  Lisp  or  C. 

To  summarize,  SodaBot  provides  the  following  capabilities: 

1.  simple,  fast  construction  of  application  agents  and  personal  assistants 

2.  support  for  complex  human/agent  and  agent/agent  communication 

3.  automated  distribution  of  new  agents 

4.  a  wide-range  of  default  behaviors  for  “typical”  situations 

Chapter  2  introduces  the  SodaBot  software  agent  paradigm,  i.e.,  essentially,  what 
we  mean  when  we  talk  about  an  agent.  We  introduce  the  automated  distribution 
of  application  agents  in  chapter  3.  The  SodaBot  agent  programming  language  is 
presented  in  chapter  4:  first,  by  way  of  example,  and  then  through  a  more  formal 
specification.  How  SodaBot  relates  to  other  current  software  agent  research  is  exam¬ 
ined  in  chapter  5.  Finally,  we  evaluate  the  system  in  chapter  6. 

1.4.1  SodaBot  agents  written  in  SodaBotL  for  a  BSA? 

The  reader  may  be  quite  pleased  that  this  document  contains  no  first-order  predicate 
calculus.  Even  so,  there  is  the  risk  that  some  of  the  new  terms  defined  here  may  cause 
confusion.  To  dispel  any  perplexity,  we  offer  the  following  guide: 

•  SodaBot  is  a  software  agent  user-environment  and  construction  system. 

•  A  SodaBot  is  a  software  agent  implemented  in  SodaBot. 

•  SodaBotL  is  the  name  of  the  programming  language  for  building  software  agents 
in  SodaBot. 

•  The  Basic  Software  Agent  (BSA)  is  the  foundation  users  build  upon  to  create 
personal  assistants  and  application  agents.  It  is  a  basic  agent  operating  system. 
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•  A  personal  assistant  is  a  simple  electronic  secretary.  It  runs  on  a  user’s  BSA. 

•  An  application  agent  is  an  agent  which  performs  a  specific  task.  It  runs  among 
the  BSA’s  that  comprise  a  SodaBot  environment. 

•  A  SodaBot  environment  is  composed  of  a  group  of  basic  software  agents  which 
communicate  with  each  other  (via  E-mail,  TCP/IP,  etc.) 

•  An  owner  or  user  is  the  human  being  directly  associated  with  a  particular  BSA. 


Chapter  2 


The  Basic  Software  Agent 


Paradigm 


This  chapter  details  the  computational  foundation  of  the  SodaBot  system  —  the 
basic  software  agent.  We  first  examine  various  configurations  for  running  the  BSA. 
We  then  detail  the  behavior  and  architecture  of  the  BSA  along  with  issues  that  arose 
during  its  implementation.  Finally,  we  discuss  the  benefits  provided  by  the  BSA 
to  software  agent  creators.  Although  this  chapter  primarily  addresses  Unix-specifics 
of  the  SodaBot  system,  presumably  parallels  exist  in  the  PC  world  to  much  of  this 
discussion. 

This  chapter  is  divided  into  the  following  sections: 

(2.1)  BSA  Installation 

(2.2)  BSA  Behavior  and  Architecture 

(2.3)  What’s  It  Good  For? 

2.1  BSA  Installation 

SodaBot  can  be  configured  to  run  in  one  of  several  ways: 
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1.  The  BSA  can  run  as  a  constant  background  job  on  some  workstation  —  usually 
(although  not  necessarily)  the  user’s  home  workstation.  This  way,  it  is  always 
ready  to  respond  to  incoming  requests,  and  if  permitted,  it  can  take  actions 
without  the  user’s  explicit  approval.  This  configuration  does  not  tie  the  BSA 
to  a  particular  display  if  the  site  permits  “xhosting”  to  other  machines;  in  this 
case,  the  user  can  simply  notify  her  BSA  of  her  current  location.  This  is  the 
default  and  simplest  way  to  configure  SodaBot. 

2.  The  BSA  can  be  run  when  the  user  logins  and  terminated  when  the  user  logs  out. 
This  option  is  appropriate  if  the  user  is  uncomfortable  leaving  SodaBot  running 
in  her  absence  or  if  option  (1)  causes  technical  complications,  e.g.,  “xhosting” 
is  not  permitted  and  she  moves  around  frequently.  This  configuration  disallows 
certain  interactions,  e.g.,  TCP/IP  connections  from  other  agents,  when  the  user 
is  not  logged  in. 

3.  The  BSA  can  be  started  dynamically  only  when  there  is:  incoming  e-mail, 
an  incoming  fax,  a  TCP/IP  connection  from  another  agent,  etc.  Unlike  with 
options  (1)  and  (2),  configuring  SodaBot  for  this  behavior  can  be  quite  difficult 
and  setting  up  the  system  requires  “user-wizardry.”  (It  generally  requires  root 
access  as  well.) 

For  option  (1),  the  user  does  nothing  more  than  start  her  BSA  by  typing  “Soda¬ 
Bot”  at  the  Unix  prompt.  The  first  time  it  is  run,  SodaBot  creates  a  directory  hi¬ 
erarchy  in  “"/.sodabot/”  that  holds  the  user’s  agent  files  and  personal  configuration 
information,  such  as  the  name  of  her  home  display.  The  BSA  also  tries  to  determine 
site  and  organization-specific  information  such  as  the  location  of  mailer  files,  system 
libraries,  and  the  name  of  institution.1  It  may  have  to  ask  the  user  several  questions 
during  installation,  but  in  the  current  implementation  this  process  is  not  generally 

institution  name  can  be  guessed  from  the  IP  address  although  the  current  table  of  known 
addresses  is  very  small  — -just  the  MIT  AI  Lab  and  AT&T  Bell  Labs. 
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interactive.  Option  (2)  merely  requires  that  the  user  start  option  (1)  and  “quit”  the 
BSA  whenever  she  logs  out.  The  BSA’s  starting  and  stopping  can  also  be  performed 
by  her  .login  and  .logout  files  respectively.  The  remainder  of  this  thesis  assumes  the 
BSA  has  been  installed  with  either  the  first  or  second  option.  While  we  have  done 
much  experimentation  with  option  (3),  the  vast  array  of  extant  Unix  configurations 
today  makes  it  simply  too  difficult  to  automate  installation,  and  the  skills  required  for 
custom  installation  are  beyond  the  capabilities  of  most  users.2  More  technical  details 
regarding  agent  configuration  for  options  (1)  and  (2)  are  discussed  in  section  2.2.2. 


2.2  The  Basic  Software  Agent 

When  it  is  not  running  an  application  agent,  the  BSA  spends  most  of  its  time  sleeping. 
However,  when  idle,  it  periodically  wakes  up  (e.g.  every  5  seconds)  and  checks  for 
(1)  incoming  e-mail;  (2)  user  activity  in  the  GUI;  (3)  a  record  “waking  up”  in  one 
of  the  system  databases;  (4)  completion  of  a  system  command  invoked  by  the  agent 
or  its  owner;  or  (5)  contact  from  another  agent.3  In  order  to  insure  responsiveness 
during  user  interaction,  the  GUI  runs  as  a  separate  process  (which  responds  to  various 
X-windows  events). 

Figure  2-1  shows  the  general  SodaBot  system  architecture.  The  BSA  is  connected 
to  available  system  resources,  and  all  application  agents  access  these  resources  through 
the  BSA.  Thus,  for  example,  the  BSA  is  solely  responsible  for  displaying  windows  on 
the  user’s  display  and  processing  her  e-mail. 

Because  application  agents  do  not  directly  access  system  resources,  the  BSA  is  free 


2If  the  user  wants  to  try  option  (3),  there  is  a  seperate  installation  program  which  can  automat¬ 
ically  generate  the  (generally)  necessary  setuid-to-root  “wrappers.”  However,  the  user  will  have  to 
connect  these  wrappers  to  the  system  files  manually.  Also  because  a  system’s  servers  rarely  honor 
setuid-to-root  flags  from  remote  clients,  the  installation  program  must  be  run  directly  on  each  server 
and  the  wrappers  must  be  stored  on  one  of  the  server’s  local  disks. 

3The  BSA’s  polling  behavior  when  idle  (i.e.  waking  up  every  few  seconds)  is  no  more  CPU 
intensive  than  that  of  other  popular  Unix  applications,  such  as  xbiff,  and  it  would  seem  to  be  a  good 
deal  less  of  a  burden  on  system  resources  than  the  ubiquitous  xload.  The  length  of  the  sleep-wake 
cycle  is  adjustable  by  the  user. 
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TCP/IP 


SodaBot  Programs 


Databases: 


Figure  2-1:  The  SodaBot  basic  software  agent  architecture 
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Figure  2-2:  Mail  handling  in  the  BSA 


at  run-time  to  reinterpret  their  access  requests.  For  example,  suppose  an  application 
agent  wants  to  display  a  message  to  the  user,  and  the  BSA  knows  that  she  is  not  at 
her  workstation  but  is  reachable  by  fax.  It  can  alternatively  fax  the  message  to  her 
in  addition  to  (or  instead  of)  displaying  the  message  on  her  screen.  This  is  dealt  with 
in  more  detail  in  section  1.3.1  in  the  chapter  covering  SodaBotL. 

Work  on  a  system  TCP/IP  connection  for  agent-to-agent  communication  is  just 
beginning.  It  will  help  alleviate  the  bottleneck  caused  by  relatively  slow  e-mail  deliv¬ 
ery  and  it  will  allow  new  or  cautious  users  to  configure  the  BSA  so  that  application 
agents  can  run  without  accessing  their  e-mail.  When  faced  with  network  “fire- walls” 
or  with  temporary  network  failures,  however,  the  BSA  will  be  able  to  resort  to  using 
e-mail  for  inter- agent  communication.4  Also,  note  that  how  messages  are  sent  be¬ 
tween  application  agents  is  actually  invisible  to  those  agents;  the  SodaBotL  Contact 
Agent  primitive  means  send  the  message  without  specifying  the  transfer  medium. 

The  connection  to  the  system  mailer  is  the  most  complicated  system  resource  link 
in  SodaBot.  (See  section  2.2.2)  In  the  standard  configuration,  the  BSA  and  its  owner 
share  the  same  mailbox.  Incoming  e-mail  can  be  intended  for  (see  figure  2-2): 

1.  The  BSA’s  owner  —  In  this  case,  it  loads  and  runs  her  specified  mail  filters  over 
each  new  message.  (Figure  2-3  contains  a  sample  filter.) 

4 Communication  via  e-mail  can  also  be  quite  useful  for  debugging  agent  applications  because  it 
is  readable  by  a  person,  unlike  TCP/IP  data. 
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Mail  filter: 

Received  mail  {from:  /las/;  subject:  /funding/}: 

Display{prompt  “Read  now?”;  choices(yes,  no,  check)} 

“Important  mail  from  Lynn!:  Ssubject”; 
if  (choice(yes))  {Display  $body;} 
elsif  (choice(check))  {System  “finger  Saddress” ; 

Display  $  result;} 

Figure  2-3:  A  SodaBot  mail  filter 

2.  A  particular  application  agent  —  Mail  can  be  directed  to  application  agents  by- 
including  a  special  SodaBot  header  in  the  message,  such  as 

To:  mhcoen@ai.mit.edu 
SodaBot:  <Pollster> 

in  which  case  it  is  directed  to  the  named  agent.  The  specification,  partic¬ 
ularly  in  headers  generated  by  other  agents,  can  also  include  a  particular 
“section”  of  the  agent  and  a  version  number,  e.g.  “SodaBot:  <Scheduler;  re¬ 
quest-meeting;  vl.0>” 

Agents  can  also  be  contacted  via  e-mail  aliases.  For  example,  the  address 
“ScheduleBot@ai.mit.edu”  can  resolve  to  “mhcoen@ai.mit.edu.”  In  this  case, 
the  BSA  is  given  a  list  of  (alias,  agent)  pairs  which  it  uses  to  resolve  the  contents 
of  the  “To:”  header  into  an  application  agent. 

3.  The  owner’s  personal  assistant  —  By  default,  the  personal  assistant  is  named 
“user_name6of@address,”  e.g.  “mhcoenbot@ai.mit.edu.” 

2.2.1  The  Basic  Software  Agent  Internals 

The  BSA  can  be  viewed  as  the  kernel  of  a  time-sharing  agent  operating  system. 
SodaBotL  programs  are  compiled  into  the  BSA’s  native  operating  language  which  is 
directly  interpreted  by  the  BSA  when  it  runs  an  agent.  The  compiled  agent  programs 
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are  divided  into  multiple  sections  which  can  be  stopped  and  restarted  by  the  BSA’s 
agent  scheduler.5 

The  agent  scheduler  allows  the  single-threaded  BSA  to  respond  to  variety  of  con¬ 
current  system  activity.  It  is  not  reasonable  for  the  BSA  to  spend  large  amounts 
of  time  waiting  for  an  some  event,  e.g.  user  input  or  completion  of  an  invoked  ap¬ 
plication  (e.g.  a  constraint-propagation  package  for  an  agent-based  planner),  at  the 
expense  of  others.  For  example,  the  mail  filter  in  figure  2-3  displays  a  message  to  the 
user  and  then  it  needs  to  wait  for  the  user’s  response  before  evaluating  the  subsequent 
if-statements.  SodaBot  handles  this  required  delay  by  putting  the  application  agent 
or  mail-filter  to  sleep  until  the  user  provides  the  requested  input  (or  the  message 
times  out).  Sleeping  agents  are  stored  in  one  of  three  sleeping  agent  databases  where 
they  wait  for  particular  events  to  occur  or  for  time  limits  to  pass.6 

When  a  BSA  receives  input  from  the  user  interface,  it  checks  the  GUI  database 
for  a  record  waiting  for  this  input.  This  record  would  contain:  (1)  the  name  of  the 
sleeping  agent;  (2)  the  position  in  this  agent  at  which  to  resume  processing;  and  (3) 
the  data  the  agent  was  running  on,  e.g.  an  e-mail  message  and  the  agent  program’s 
local  state.  If  the  appropriate  record  is  found,  its  corresponding  agent  is  then  reloaded 
and  continues  running  until  completion  or  until  the  next  expression  which  causes  it 
to  wait. 

The  BSA  also  has  a  database  for  dealing  with  the  SodaBot  “system”  command, 
which  can  be  used  to  access  local  software,  e.g.,  the  “finger”  command,  LaTeX, 
ghostscript,  etc.  The  system  command  can  take  an  arbitrary  amount  of  time  to 
finish,  so  the  BSA  creates  a  separate  process  to  run  the  specified  command  and  puts 
the  agent  to  sleep  in  the  system  database.  The  BSA  will  continue  with  some  other 

5SodaBot  is  written  in  Perl,  Extended  TCL/TK,  and  C.  This  part  of  the  system  is  implemented 
in  Perl,  a  language  which  provides  little  support  for  this  type  of  non-local  program  flow.  In  order 
to  permit  it,  agent  programs  get  divided  into  many  individual  procedures,  each  of  which  must  be 
called  in  order  to  execute  the  agent.  Thus,  we  can  interrupt  an  agent’s  execution  by  pausing  between 
subroutine  invocations. 

sMail  filters  are  actually  run  by  the  internal  mail  filter  agent  which  can  also  be  placed  in  one  of 
the  sleeping  agent  databases. 
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activity.  When  it  hears  that  the  command  has  completed  (over  a  Unix-style  socket), 
the  BSA  will  reload  the  sleeping  agent  with  the  command’s  output  stored  in  the 
Sresult  variable. 

The  third  database  is  for  incoming  messages  which  have  been  directed  to  an 
unknown  application  agent.  When  e-mail  is  sent  to  an  agent  that  the  BSA  does 
not  know  about,  the  BSA  requests  that  the  specified  agent  be  supplied  either  by 
the  original  sender  or  by  a  central  agent  depository.  Until  that  agent  arrives  (as  a 
SodaBotL  program),  the  mail  is  held  in  the  delivery  database.  Automatic  distribution 
of  agents  is  discussed  in  chapter  3. 

Agents  can  specify  maximum  lengths  of  time  they  are  willing  to  spend  sleeping  in 
a  database.  After  this  timeout  expires,  the  agent  is  restarted  at  some  specific  error- 
recovery  or  expired-timeout  point  where  it  can  take  remedial  or  default  action,  such 
as  re-sending  a  request  or  notifying  its  owner  of  the  problem.  Certain  error-recovery 
protocols  are  built-in  to  SodaBot,  such  as  recovery  from  failure  to  receive  requested 
agent  programs. 

2.2.2  Agent  Configuration 

The  user  can  configure  the  BSA  based  on  both  her  preferences  for  its  behavior  (see 
section  )  and  the  amount  of  confidence  she  has  in  its  correct  operation.  For  example, 
once  the  BSA  has  the  ability  to  communicate  directly  via  TCP/IP,  it  will  be  capable 
of  running  without  accessing  the  user’s  e-mail  if  she  so  desires;  additionally,  the  BSA’s 
ability  to  run  local  software  can  be  greatly  curtailed  or  eliminated.  It  seems  quite 
essential,  particularly  because  SodaBot  is  a  new  and  experimental  system,  that  we 
provide  people  with  a  minimally  risky  way  of  using  it.  Thus,  the  BSA’s  connections 
to  specific  system  resources  can  be  temporally  or  permanently  disabled.  As  the  user 
becomes  more  comfortable  with  the  system,  she  can  selectively  re-enable  features. 

Users  can  also  determine  precisely  how  the  BSA,  if  permitted,  processes  their  e- 
mail.  This  is  actually  a  rather  complex  issue,  and  there  are  many  technical  details 
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that  are  not  sufficiently  interesting  to  document  here.  For  example,  there  are  (too) 
many  ways  to  connect  a  BSA  to  the  system’s  mailer.  The  simplest  way  is  for  the 
BSA  and  its  owner  to  share  the  same  mailbox  file.  In  this  case,  we  would  like  the 
BSA  to  quickly  remove  its  messages  from  this  file  so  the  sharing  is  transparent  to 
the  user.  However,  in  Unix,  there  are  certain  file  locking  problems  on  distributed  file 
systems  which  could  cause  a  program  that  writes  to  a  mail  spooler  file  to  clobber 
incoming  mail.7  In  response  to  this  problem,  SodaBot’s  default  configuration  does 
not  write  user-messages  back  to  the  spooler  file  after  it  removes  mail  intended  for 
the  BSA.  Thus,  the  user  needs  to  obtain  her  new  messages  from  somewhere  other 
than  the  system-mailer’s  spool  file;  therefore,  she  must  explicitly  provide  a  location 
for  this  new  spool  file,  and  inform  her  mail-reader  of  its  existence.8  It  is  also  possible 
for  the  BSA  to  have  its  own  e-mail  address  (as  done  in  [Kautz  et  ah,  1994]),  but  on 
some  systems  this  can  require  root  access  to  set  up. 

2.3  The  Benefit 

The  basic  software  agent  provides  preliminary  solutions  to  the  three  problems  outlined 
in  section  1.2  with  software  agent  construction.  More  importantly,  it  is  a  foundation 
for  other  components  of  the  SodaBot  system,  e.g.  SodaBotL,  to  more  completely 
address  these  issues. 

1.  Software  agents  can  be  technically  challenging  to  write  in  traditional  program¬ 
ming  languages  and  operating  systems: 

•  We  discussed  earlier  the  three  coding-layers  typically  involved  in  software 
agent  construction:  (1)  low  level,  e.g.  networking;  (2)  mid  level,  e.g.  error 
handling;  and  (3)  high  level,  e.g.  knowledge  representation.  The  BSA 

7The  problem  here  is  quite  technical  —  it  involves  the  distinction  between  lockf(3)  and  fcntl(2v) 
—  and  occurs  only  very  rarely,  but  I  have  verified  its  existence  with  local  GNU  mail-wizards. 

8If  she  prefers,  the  user  can  have  her  BSA  write  back  to  the  mail-spooler  file.  The  risks  are  no 
greater  than  if  she  did  so  herself  using  one  of  the  more  popular  mail  reading  programs. 
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helps  free  the  agent  creator  from  the  first  two  of  these  efforts  so  that  she 
can  concentrate  on  the  third.  It  pushes  system-specific  aspects  of  agent 
creation  beyond  the  abstraction  barrier. 

2.  Software  agents  are  difficult  to  distribute  because  they  may  have  site-specific 
dependencies;  for  the  same  reason,  they  can  be  difficult  to  install. 

•  The  BSA  disconnects  application  agents  from  the  specific  computational 
environment  in  which  they  run.  Agent  programs  no  longer  need  to  be 
“hard-coded”  with  site-specific  information. 

•  This  disconnection  makes  it  easy  to  move  agents  around.  They  don’t  need 
to  be  disconnected  from  their  “birth-site”  or  hooked-up  to  anything  when 
being  installed. 

•  The  problem  of  configuring  many  software  agents  is  reduced  to  the  problem 
of  configuring  a  single  agent,  i.e.,  the  BSA. 

•  The  BSA  has  knowledge  of  several  standard  Unix  configurations  and  tries 
to  automate  its  installation. 

3.  People  may  be  uncomfortable  with  the  amount  of  responsibility  given  to  an 
unknown  (and  possibly  buggy)  agent. 

•  The  BSA  allows  the  user  to  gradually  establish  confidence  in  its  behavior 
and  to  selectively  disable  and  enable  access  to  specific  system  resources. 

•  The  agent-system  disconnection  allows  the  BSA  to  reinterpret  at  run-time 
requests  for  system  resources  from  application  agents.  Users  can  therefore 
customize  the  behavior  of  application  agents  without  actually  modifying 
them. 

•  The  BSA  provides  a  stable  agent-framework  over  which  the  user  can  exert 


ultimate  control. 


Chapter  3 

Distributed  Agents  in  SodaBot 


In  SodaBot,  an  application  agent  generally  doesn’t  run  as  a  single  program  on  a 
particular  basic  software  agent.  Rather,  various  sections  of  an  agent  are  automatically 
distributed  to  and  run  on  the  BSAs  which  comprise  a  SodaBot  environment.  The 
agent’s  activity  is  manifested  by  the  coordinated  interaction  of  these  program  sections. 

This  chapter  discusses  how  SodaBot  agent  programs  are  structured  and  how  they 
are  distributed.  We  are  concerned  here  only  with  how  SodaBotL  programs  are  orga¬ 
nized  and  how  they  move  around  the  network,  not  with  what  they  actually  do  (or 
“mean”)  once  they  arrive  at  their  destination.  It  might  seem  a  little  odd  to  discuss 
how  SodaBotL  programs  travel  before  saying  what  it  is  they  actually  do.  However, 
because  understanding  agent  distribution  is  fundamental  to  writing  a  SodaBot  agent, 
we  present  it  before  detailing  SodaBotL’s  semantics  (in  Chapter  4). 

We  also  discuss  several  related  issues,  including  SodaBot  environment  topology 
and  security  concerns  inherent  in  any  automated  distribution/installation  of  software. 
Security  against  malicious  adversaries  was  at  best  a  peripheral  consideration  during 
the  design  of  the  current  implementation  of  SodaBot.  However,  it  is  a  very  interesting 
research  topic  and  one  we  hope  to  explore  in  the  future. 
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3.1  The  Anatomy  of  an  Agent 

A  SodaBot  environment  is  formed  by  a  group  of  basic  software  agents  which  coopera¬ 
tively  implement  an  application  agent.  These  agents  may  all  be  running  on  the  same 
physical  machine  or  they  may  be  distributed  across  a  network,  each  running  (in  the¬ 
ory)  on  a  different  operating  system  and  platform.  An  individual  BSA  is  most  likely 
a  member  of  several  different  environments,  each  expressing  the  unique  connectivity 
required  for  a  particular  application  agent.  - 

SodaBotL  programs  are  composed  of  (possibly  overlapping)  groups ,  where  each 
group  represents  a  different  distribution  of  sections  of  the  agent’s  program.  Groups 
specify  what  role  the  agent  requesting  software  is  going  to  play  in  the  execution  of  this 
agent.  For  example,  the  simplest  group  labellings  might  be  “client”  and  “server;”  one 
BSA  might  then  contact  another,  “I  need  section  X  of  agent  Y,”  where  section  X  is  in 
the  “client”  group.  Then  all  sections  of  agent  Y  in  the  “client”  group  would  be  sent 
out  to  the  requesting  agent;  presumably,  in  its  role  as  a  “client,”  it  will  need  access 
to  the  other  sections  of  agent  Y  which  also  fall  into  this  group.  However,  SodaBot 
doesn’t  enforce  this  model;  agents  can  have  more  than  two  groups  and  individual 
BSAs  can  fall  in  more  than  one  group.  It  may  also  not  be  computable  a  priori  which 
BSAs  will  end  up  in  which  groups  when  the  agent  is  running.  As  an  agent  gets  added 
to  more  groups,  it  may  have  to  issue  additional  requests  to  obtain  the  sections  of  the 
agent  associated  with  them. 

Figure  3-1  outlines  the  generic  SodaBot  application  agent  structure.  An  appli¬ 
cation  agent  is  divided  into  various  sections  (numbering  corresponds  to  that  in  the 
figure): 

1.  Global  declarations  —  These  are  declarations  which  get  distributed  to  every 
BSA  running  the  agent. 

2.  The  main  agent  —  This  section  specifies  what  happens  when  the  agent  gets 
invoked.  Notice  there  is  no  group  expression  specified  here.  Presumably,  a 
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Figure  3-1:  The  generic  SodaBot  agent  anatomy 
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BSA  that  requests  this  part  of  the  agent  needs  all  the  other  sections  as  well  so 
that  it  can  in  turn  distribute  them.  So,  a  BSA  that  requests  the  agent  without 
specifying  a  group  is  sent  the  entire  agent.  The  Required  input  specifies  the 
format  of  the  input  which  must  be  supplied  to  the  agent.  The  body  is  a  list  of 
SodaBotL  expressions. 

In  the  current  implementation  of  SodaBot,  agents  can  only  be  invoked  via  e- 
mail.1  For  example,  one  might  send  the  following  structured  message  to  the 
hypothetical  Authorize  agent  (which  will  be  presented  more  fully  in  section  4.1): 


To:  authorize@ai.mit.edu 

as  input  to  Agent  authorize: 

Required  input  { 

Person  1:  las 

person  1:  *username 

Person  1:  brooks 

person2:  *username 

pathname:  ~  mhcoen/tr.ps 

pathname:  ^pathname} 

Note  that  the  structured  input  is  in  the  body  of  the  message,  not  its  header. 


3.  Request  RequesLi  —  Requests  are  atomic  sections  of  agents  which  get  dis¬ 
tributed  to  and  run  on  members  of  its  environment;  essentially,  an  application 
agent’s  requests  are  simply  what  different  BSAs  can  ask  each  other  to  do  while 
running  the  agent;  group  membership  simply  determines  which  requests  a  BSA 
is  allowed  to  issue.  Note  that  each  request  must  specify  to  which  group(s)  it 
belongs.  One  BSA  can  issue  a  request  to  another  BSA  by  sending  e-mail  to  its 
owner  such  as: 


To:  las@ai.mit.edu 

SodaBot:  <  authorize;  certifyy 

SodaBot- Parser:  <l:l;s:0;e:35.  l:2;s:18;e:13.> 

Michael  H.  Coen  (mhcoen@ai.mit.edu)  requests  that  you  authorize 
the  submission  in  "mhcoen/tr.ps 


1  We  hope  to  soon  also  make  them  accessible  via  the  graphic  user  interface.  In  a  straightforward 
way,  we  can  generate  a  graphic  input-window  based  on  the  Required  input  specification.  Most  likely 
it  will  look  very  much  like  the  form  input  type  in  Mosaic. 
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The  “SodaBot-Parser:”  header  is  used  by  the  receiving  BSA  to  determine  where 
SodaBotL  variables  have  been  substituted  into  the  message  body  by  the  agent 
that  sent  it.  For  example,  the  first  argument  in  this  case  ( $requester )  is  on  line 
1  of  the  message,  starting  at  position  0,  and  runs  for  35  characters.  Requests 
can  also  specify  Required  input  which  is  used  if  the  message  was  sent  by  a  person 
rather  than  a  BSA. 

4.  Subroutines  SubA  —  Subroutines  are  called  only  by  requests,  not  other  sub¬ 
routines.  If  they  list  no  group  membership,  only  the  main  agent  has  access  to 
them.  Otherwise,  they  are  distributed  with  their  respective  groups  the  same 
way  requests  are. 

3.2  A  Sample  Distribution 

We  now  consider  the  simplest  type  of  distribution  —  that  between  peers  —  with  the 
Pollster  agent  introduced  in  section  1.3.2.  Suppose  Patrick  creates  (or  updates)  this 
agent  and  then  sends  e-mail  directed  to  Gerry’s  Pollster.2  (See  figure  3-2.)  Upon 
receipt  of  this  message,  Gerry’s  BSA  checks  whether  it  has  a  Pollster  agent.  In  order 
that  we  have  something  to  say  here,  let’s  assume  that  it  doesn’t.3  Then,  Gerry’s 
BSA  places  the  incoming  Pollster  message  in  its  delivery  database,  which  consists 
of  messages  awaiting  the  arrival  of  application  agent  software.  It  then  requests  that 
Patrick’s  BSA  supply  the  Pollster  agent  program.  When  it  arrives,  Gerry’s  BSA 
compiles  the  Pollster  SodaBotL  program  and  then  starts  the  Pollster  on  the  messages 
in  the  delivery  database  that  were  awaiting  its  arrival. 

Every  BSA  has  two  built-in  agents  called  the  RequestAgent  and  the  Delivery  A  gent. 

2Software  updates  are  distributed  like  new  software  and  are  indicated  by  providing  a  higher  than 
current  version  number. 

3Another  issue  that  arises  with  agent  distribution  is  developing  a  common  namespace.  Suppose 
Gerry’s  BSA  did  have  a  Pollster  agent,  but  a  different  one  than  intended  by  Patrick.  Currently, 
the  only  way  to  handle  this  problem  is  to  specify  not  only  the  agent  name,  but  also  its  flavor  and 
version,  such  as  “<Pollster,  Patrick;  vl>”. 


CHAPTER  3.  DISTRIBUTED  AGENTS  IN  SODABOT 


37 


Patrick 


To:  gjs@martigny 
S©daBofcPc//s/6r> 

1  think  Lisp  is  better  than 
sliced  bread. 

Sod  aBot  <  RequestAgent 
Send:  Pollster; main 


/SodaBol<  Delivery  Agent  ">\ 


X^RIes:  Pollster; main  ]  ) 


Pollster 


(1)  Request  agent  and  wait 
for  its  files  to  arrive 

(2)  Perform  security  checks  on  agent 

(3)  Compile  and  install  agent 

(4)  Start  agent  on  original  message 


Figure  3-2:  Distribution  of  the  Pollster  agent 


When  a  RequestAgent  receives  a  request  to  provide  some  section  of  an  application 
agent,  it  tars,  compresses,  and  mails  the  SodaBotL  program  corresponding  to  that 
section  to  the  requester’s  Delivery  Agent.  In  turn,  when  a  DeliveryAgent  receives  a 
previously  requested  agent,  it  unpacks  the  incoming  program  and  uses  the  SodaBot 
compiler  to  install  the  agent  after  taking  whatever  security  precautions  (discussed 
below)  that  it  has  been  configured  for. 

In  this  example,  the  Pollster  agent  is  an  atomic  whole  and  requesting  it  is  an 
all-or-nothing  affair;  it  is  not  broken  down  into  groups.  However,  “peer  distribution” 
doesn’t  require  this.  What  is  important  is  that  when  Gerry’s  BSA  asks  for  the  Pollster 
agent,  Patrick’s  BSA  is  ready  to  supply  it.  When  the  groups  an  agent  contacts  are  a 
subset  of  its  own,  then  we  call  the  resulting  transfer  of  software  a  “peer  distribution,” 
i.e.  your  peer  can  supply  you  with  the  software  it  is  requesting  that  you  run. 

3.3  Network  Topology 

What  happens  when  an  agent’s  environment  is  more  complex?  Unlike  like  with  the 
simple  peer  distribution  above,  sections  of  agent  may  contact  other  groups  in  the 
agent  of  which  they  are  not  members;  therefore,  how  do  they  supply  any  requests  for 
these  groups’  software? 


Possible  solutions  include: 
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•  If  an  agent  doesn’t  have  the  software,  presumably,  one  of  its  “ancestors”  does. 
So,  it  should  relay  the  request  to  its  “parents”  and  pass  on  their  responses. 

This  can  require  0((n/(n  -g  +  l))2)  separate  communications  overall,  where  n 
is  the  number  of  BSA’s  involved  and  g  is  the  number  of  groups  in  the  agent.  It 
can  incur  long  communication  delays,  particularly  if  done  by  e-mail. 

•  If  an  agent  contacts  another  whose  software  it  doesn’t  have,  it  should  include 
the  the  name  of  either:  (1)  its  “parents”;  or  (2)  the  name  it  was  given  to  contact 
for  software  (if  one  was  provided).  Thus,  requests  can  be  sent  to  them  directly, 
and  the  agent  is  removed  from  any  ensuing  communication  regarding  obtaining 
the  software. 

This  can  require  0(ng)  separate  communications  overall;  assuming  unit  cost  for 
processing  requests,  this  is  perhaps  the  minimum  we  can  expect.4  Note  that 
the  communication  patterns  that  invoke  the  upper  bound  here  and  in  the  case 
above  are  not  necessarily  bizarre  or  unlikely.  However,  these  are  only  start-up 
costs  —  invoked  only  the  first  time  the  agent  is  run  or  when  it  is  updated  —  so 
they  may  be  quite  tolerable. 

•  We  set  up  a  central  agent  depository  which  keeps  all  current  agents  in  a  library, 
available  upon  request. 

This  is  the  solution  we  currently  prefer  for  SodaBot.  However,  it  is  conceiv¬ 
able  that  some  applications  may  not  be  freely  distributable,  due  to  secrecy, 
export  limitations,  software/patent  licenses,  etc.  Thus,  we  might  need  to  pro¬ 
vide  guarantees  of  limited  access.  We  have  not  looked  into  this  issue,  but  it 
would  seem  a  secure  protocol  —  perhaps  via  a  kerberos  ticketing  scheme  — 
might  be  developed  to  do  this. 

4 The  caveat  is  that  a  single  BSA  may  receive  a  flood  of  requests  for  agent  programs  from  all  of 
its  descendants. 


CHAPTER  3.  DISTRIBUTED  AGENTS  IN  SODABOT 


39 


•  Do  away  with  group  distinctions  and  send  out  agents  in  their  entirety.  Then, 
everybody  has  everything  they  need. 

Note  that  application  agents  may  contact  completely  different  agents  —  e.g. 
the  Scheduler  can  contact  the  RoomCoordinator  —  not  merely  other  parts  of 
the  same  agent.  Should  we  require  that  every  BSA  possess  every  application 
agent?  Also,  the  distribution  limitation  issues  discussed  above  apply  here  as 
well  —  effectively  ruling  out  this  option. 

3.4  What’s  the  Risk? 

There  are  genuine  security  concerns  for  this  (and  any  other)  method  of  automatic 
software  distribution.  In  the  introduction,  we  noted  that  no  one  is  likely  to  ftp 
and  install  random  software  that  could  send  e-mail  in  her  name.  All  the  more  so, 
shouldn’t  a  user  be  concerned  about  random  software  which  can  simply  appear  on 
her  workstation  without  her  involvement? 

Currently,  SodaBot  can  be  configured  with  several  simple  options  including: 

•  Don’t  compile  received  agents  which  use  the  system  command. 

•  Ask  for  owner  permission  before  compiling  such  agents.  However,  if  the  user 
has  to  read  a  program,  what  advantage  does  SodaBot  provide?  Simply  that 
the  programs  are  much  shorter  and  easier  to  understand.  We  would  argue  that 
malicious  behavior  is  therefore  more  easily  detected. 

•  Insure  that  application  agents  only  access  files  and  execute  commands  in  par¬ 
ticular  user-specified  directories. 

A  user  is  free  to  limit  the  system  access  given  to  her  BSA,  thereby  limiting  the 
access  available  to  all  application  agents.  She  can  also  require  that  her  BSA  (and 
therefore  application  agents  as  well)  obtain  explicit  permission  before  taking  certain 
actions,  e.g.  sending  e-mail. 
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We  hope  to  add  more  sophisticated  security  measures  such  as  encrypting  the 
distribution  of  agents  to  guarantee  authenticity  and  integrity. 

3.5  The  Benefit 

SodaBot’s  automatic  distribution  of  application  agents  addresses  the  second  and  third 
of  the  problems  outlined  earlier  with  software  agent  construction: 

(2)  Software  agents  are  difficult  to  distribute  because  they  may  have  site-specific 
dependencies;  for  the  same  reason,  they  can  be  difficult  to  install. 

•  Agents  in  SodaBot  distribute  themselves  over  the  Internet  and/or  local 
area  networks.  This  distribution  can  even  be  across  platforms  and  operat¬ 
ing  systems.  Simply  put,  acquisition  of  new  agents  does  not  require  that 
the  user  do  anything. 

(3)  People  may  be  uncomfortable  with  the  amount  of  responsibility  given  to  an 
unknown  (and  possibly  buggy)  agent. 

•  SodaBot  simultaneously  helps  alleviate  and  further  exacerbates  this  prob¬ 
lem.  The  BSA  is  a  trusted,  much  tested  framework,  and  its  behavior  is 
under  the  ultimate  authority  of  its  owner.  Regardless  of  this,  however, 
automated  software  distribution  would  seem  to  get  many  people  very  ner¬ 
vous.  Hopefully,  additional  efforts  to  protect  against  malicious  adversaries 
will  provide  sufficient  reassurance. 


Chapter  4 


Writing  SodaBot  Agents 


This  chapter  presents  SodaBotL  —  the  SodaBot  agent  programming  language.  We 
described  in  chapter  3  how  an  application  agent  gets  distributed  in  sections  to  the 
BSAs  comprising  its  environment.  Now,  it’s  time  to  discuss  what  these  programs 
actually  mean  —  both  to  the  people  who  write  them  and  the  BSAs  that  receive 
them. 

By  way  of  example,  we  first  outline  how  to  create  a  SodaBot  application  agent 
that  involves  interactions  among  several  people.  We  then  present  a  SodaBotL  pro¬ 
gramming  reference  guide  and  discuss  the  benefits  provided  by  SodaBotL  to  software 
agent  creators.  Note,  Appendix  B  contains  a  SodaBotL  BNF  grammar. 


4.1  Agents  Describe  Dialogs 

Chapter  3  described  how  SodaBot  application  agents  run  across  a  network  of  inter¬ 
connected  BSAs.  Generally,  no  single  BSA  runs  an  entire  agent  program;  rather,  each 
BSA  falls  into  one  or  more  groups  and  runs  only  those  particular  sections  of  an  agent 
that  correspond  to  its  group  membership. 

Our  model  for  writing  agents  is  that  agent  execution  corresponds  to  a  series  of 
dialogs  among  the  BSAs  that  comprise  the  agent’s  environment.  Thus,  while  running 
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a  particular  agent,  a  BSA’s  group  membership  determines  who  it’s  allowed  to  speak 
with  and  what  it’s  allowed  to  say  in  a  series  of  conversations  with  people  and  other 
BSAs.  We  use  “conversation”  here  somewhat  freely;  we  consider  the  BSA’s  owner 
making  a  selection  in  the  GUI,  an  incoming  fax,  or  mail  from  another  agent  to  be 
among  the  things  that  the  BSA  can  listen  to.  In  turn  the  BSA  can  process  what  it 
hears  and  then  communicate  it  via  the  GUI,  fax  machine,  TCP / IP,  etc. 

So,  each  request  section  of  an  agent’s  SodaBotL  program  expresses  the  agent’s 
reaction  to  “hearing”  a  particular  request  while  running  on  a  BSA  in  its  environment. 
In  the  framework  of  a  conversation  then,  each  request  section  of  the  program  must 
specify: 

1.  What  to  listen  for  —  This  is  the  section’s  permissible  input.  It  can  consist  of 
a  required  format  for  incoming  e-mail  and/or  an  input  specification  from  the 
user  through  the  GUI. 

2.  What  to  do  with  it  —  This  specifies  how  to  process  what  the  agent  “hears,” 
including  searching  the  input,  textually  manipulating  it,  saving  it  to  a  file,  or 
feeding  it  to  some  external  program. 

3.  How  to  continue  the  conversation  —  If  it  is  not  finished,  the  agent  needs  to 
“pass  the  buck,”  by  issuing  one  or  more  requests  to  BSAs  in  its  environment 
and  thereby  create  continuing  threads. 

Thus,  an  agent  writer  outlines  the  shape  of  a  dialog,  i.e.  what  inputs  are  al¬ 
lowed  in  the  dialog,  how  they  should  be  transformed,  and  how  to  communicate  them. 
Figure  4-1  presents  a  simple  authorize  agent  for  sanctioning  document  publication.1 
This  agent  was  designed  according  to  MIT  AI  Lab’s  procedure  for  authorizing  the 
publication  of  memos  and  technical  reports.  Our  experience  designing  other  ad  hoc 

xThe  current  running  SodaBot  compiler  uses  a  slightly  different,  less  readable  syntax  than  the  one 
presented  here.  We  are  working  towards  making  the  syntax  given  here  the  standard  for  SodaBotL 
and  had  initially  hoped  it  would  be  ready  by  the  publication  date  of  this  thesis.  However,  the  new 
compiler  is  not  finished.  We  are  presenting  only  the  new  syntax  in  the  body  of  this  document.  See 
Appendix  A  for  details  relevant  to  the  current  implementation. 
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Jauth-dest  =  “publication5@ai.mit.edu”; 

Agent  authorize: 

Required  input  { 
personl:  *username 
person2:  *username 
pathname:  *pathname} 

Srequester  =  Sfrom; 

Contact  Agent  <authorize;  certify>  {users:  Spersonl,  Sperson2}: 

“Srequester  requests  that  you  authorize  the  submission  in  Spathname”; 

Request  certify:  {group  signer} 

Display  {prompt  “Do  you  want  to  see  the  file  now?”;  ehoices(yes,  no,  view)}: 

“You  have  been  requested  to  authorize  Spathname  by  Srequester”; 
if  choice(yes)  { 

Load  Spathname  $contents; 

Display  {prompt  “Do  you  want  to  authorize  this?”;  choices(yes,  no)}: 
Scontents;} 

if  choice(yes)  {& grant_aufc horization  } 
elsif  choice(view)  { 

System  “ghostscript  Spathname”; 

Display  {prompt  “Do  you  want  to?”;  choices(yes,  no)}: 

“You  have  been  requested  to  authorize  Spathname  by  Srequester”; 
if  choice(yes)  {&grant_authorization  }} 

Request  grant: {group  publications} 

Display: 

“Authorization  received  from  Sfrom  for  Srequester  for  file  Spathname”; 
SrecordJfile  =  “/home/com/publications/Srequester. Spathname”; 

Save  {append}  $record_file  Smessage; 

Subroutine  grant-authorization  {group  signer}{ 

Contact  Agent  <authorize;  grant>  {users:  Sauth.dest}: 

“I  grant  authorization  to  Srequester  for  file  Spathname.”;} 


Figure  4-1:  A  SodaBot  authorize  agent  for  approving  document  publication 


task-specific  software  agents  leads  us  to  estimate  that  an  agent  of  this  complexity 
would  optimistically  require  several  weeks  of  implementation  time  and  roughly  50 
pages  of  code.  This  SodaBot  agent  took  10  minutes  to  write  and  is  approximately 
one  page  in  length. 

The  SodaBot  version  of  the  document  publishing  process  works  as  follows: 

1.  The  document  author  sends  mail  to  the  authorize  agent  at  an  abased  “pubhcations” 
e-mail  address.  This  mail  contains  the  name  of  two  “authorized  signers”  and  the 
pathname  of  the  viewable  document. 

2.  The  authorize  agent  contacts  the  authorized  signers  by  sending  mail  to  the  certify 
section  of  their  authorize  agents. 

3.  The  authorized  signers  are  given  the  opportunity  to  examine  the  document  and  certify 
it. 


4.  Authorizations  are  sent  back  to  the  pubhcations  officer  and  recorded. 
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In  this  example,  the  BSAs  of  the  authorized  signers  run  the  signer  section  of  the 
agent,  and  the  BSA  of  the  publications  officer  runs  the  publications  section.  Recall 
that  the  “group”  specifications  in  the  SodaBotL  program  determine  which  other  sec¬ 
tions  of  the  program  get  distributed  when  a  BSA  requests  some  specific  portion.  For 
example,  when  the  BSA  of  an  authorized  signer  first  requests  the  certify  section  of 
the  authorize  agent,  it  is  also  sent  all  other  members  of  the  signer  group,  in  this  case, 
the  grant-authorization  subroutine. 

It  is  essential  that  messages  mailed  by  agents  be  readable  by  people  who  do  not  use 
SodaBot.2  Therefore,  agents  must  send  human-readable  text.  Note  that  the  certify 
section  refers  directly  to  variables,  such  as  $requester ,  which  have  been  substituted 
into  the  text  message  it  receives  without  any  explicit  parsing  of  the  message  body 
or  requirements  for  structured  format.  This  is  achieved  by  including  an  unobtrusive 
extra  header  in  the  message  which  contains  minimal  sufficient  information  for  deter¬ 
mining  the  demarcations  of  the  text  substituted  for  the  variables  referenced  by  the 
receiving  agent.  (Page  35  illustrates  such  a  header.)  The  BSA  automatically  extracts 
this  text  and  stores  it  in  the  appropriate  local  variable(s).3 

4.2  SodaBotL  Reference  Manual 

This  section  is  an  abbreviated  guide  to  programming  in  SodaBotL.  Readers  who  know 
C  or  Perl  may  find  it  useful  to  keep  in  mind  that  SodaBot 's  syntax  is  loosely  related 
to  each  of  theirs. 

We  discuss  in  this  section  the  following  topics: 

(4.2.1)  Where  the  BSA  looks  for  things 

2 Of  course  we  exclude  here  messages  intended  for  SodaBot’s  internal  use,  such  as  a  request  for 
agent  distribution. 

3SodaBot  currently  does  not  interact  well  with  people  who  do  not  have  SodaBot  BSA’s.  We  are 
currently  adding  automated  construction  of  a  structured  text  form-generator  based  on  the  required 
input  specification.  This  will  be  coupled  with  automated  error  handling  for  user  text-based  input 
which  differs  from  an  agent’s  specified  input  format  that  will  result  in  appropriate  explanatory  error 
messages. 
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(4.2.2) 

Variables  in  the  BSA 

(4.2.3) 

Conditionals 

(4.2.4) 

How  to  write  a  mail  filter 

(4.2.5) 

How  to  write  an  application  agent 

(4.2.6) 

SodaBotL  primitives 

4.2.1 

SodaBot  File  Hierarchy 

When  a  user  first  runs  SodaBot,  it  creates  a  directory  hierarchy  in  “"/.sodabot/.” 
The  top-level  subdirectories  in  this  hierarchy  are: 

1.  Agents  —  Contains  compiled  SodaBot  application  agents. 

2.  AgentsSrc  —  Contains  the  SodaBotL  sources  to  all  agents  received  by  the  BSA 
and  to  agents  written  by  its  owner.  Each  application  agents  is  kept  in  a  separate 
subdirectory. 

3.  DBase  —  Stores  the  sleeping,  system,  and  delivery  databases. 

4.  Lib  —  Internal  SodaBot  library  files 

5.  Log  —  Stores  the  BSA’s  extensive,  human  readable  logs  of  its  activity. 

6.  NonAgents  —  Contains  compiled  SodaBot  mail  filters. 

7.  NonAgentsSrc  —  Contains  the  SodaBotL  sources  to  the  mail  filters. 

8.  SodaBot  —  Internal  SodaBot  directory,  stores  information  about  owner. 

Users  can  create  new  agents  and  mail  filters  through  the  SodaBot  agent  editor ,  or 
they  can  write  and  compile  SodaBotL  files  directly.  The  agent  editor  is  invoked  via 
the  “Programmer”  menu  in  the  main  GUI  window.  (See  figure  1-2.)  The  SodaBotL 
compiler  looks  for  its  input  in  the  appropriate  “Src”  directories  and  places  compiled 
output  in  the  appropriate  object  file  directories.  A  sample  interaction  might  be: 

mhcoen@double-chex>  compile  test.sbt 

SodaBot  Compiler  Vl.l  running. 
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Reading  /home/c2/mhcoen/.sodabot/NonAgentsSrc/test.sbt 
Checking  syntax  of  syntax  of  compiled  program... 

Writing  program  to  /home/c2/mhcoen/.sodabot/NonAgents/test.pla 

4.2.2  Variables 

All  variables  in  SodaBotL  are  prefaced  with  a  $.  Variables  are  typed  according  to 
their  current  context,  so  no  explicit  type  declaration  is  necessary;  for  example,  “10” 
can  be  either  a  number  or  a  string,  depending  on  how  it  is  used.  Variable  assignment 

and  reference  work  as  you  would  expect.  Here  are  some  sample  expressions: 

$name  =  Susername; 

$a ddress  =  “545  Technology  Square 
Cambridge,  Ma  02139\n 
Mail  to  $host: 

“My  snail-mail  address  is  :\n$name\n  $  address  ”  ; 

Strings  can  be  multiline  and  can  contain  \“  to  quote  things,  e.g. 

$quotedjstring  =  ‘\“Inside  Quotes!\””; 

The  BSA  automatically  defines  a  number  of  variables.  These  include  variables 
corresponding  to  all  headers  present  in  the  current  e-mail  message  as  defined 
by  [Horton,  1983].  (For  example,  $from  and  $subject.  See  the  BNF  “Field”  pro¬ 
duction  on  page  73  for  a  list  of  all  valid  headers.)  Also,  the  following  are  always  kept 
current: 


Variable  name 

Description  of  value 

$home 

user’s  home  directory 

$user[-]name 

user’s  full  name 

SuserJogin,  $me 

user’s  login  name 

Smessage 

the  complete  text  of  the  current  message 

$body 

the  body  of  the  message 

•Shame 

sender’s  full  name  if  specified 

$a  ddress 

sender’s  e-mail  address 

$reply-to 

if  not  specified,  value  of  Sfrom  is  used 
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4.2.3  Conditionals 

Conditionals  in  SodaBotL  perform  regular  expression  matching  and  numerical  com¬ 
parisons: 


Expression 

True  if 

($a  eq  $b) 

$a  and  $b  are  equivalent 

($a  eq  “moo”) 

$a  equals  the  string  “moo” 

($a  neq  $b) 

$a  and  $b  are  not  equivalent 

($a  =~  /Sb/) 

$a  contains  $b 

($a  =~  /moo/) 

$a  contains  “moo” 

($a  =~  A d+/) 

$a  contains  a  number,  etc. 

($a  !  ~  /Sb/) 

$a  doesn’t  contain  $b,  etc. 

($a  ==  $b) 

$a  and  $b  are  numerically  equal 

($a  <=  $b) 

$a  <  $b,  etc. 

Regular  expression  are  contained  in  do  not  require  internal  quotations.  Good 

references  for  building  regular  expressions  are  [Wall  and  Schwartz,  1990,  p24-29]  and 
[Dougherty,  1990]. 

You  can  use  kk  for  AND  and  ||  for  OR  and  !  for  NOT.  Conditionals  can  be  nested 
in  the  standard  way,  e.g 

if  (((Shorn  eq  “las”)  ||  (Shorn  eq  “gjs”))  kk  (Ssubject  =~  /6\.001/)) 

4.2.4  Writing  a  Mail  Filter 

The  BSA  can  execute  a  series  of  SodaBotL  expressions  upon  the  arrival  of  specific 
incoming  e-mail.  The  user  specifies  which  e-mail  triggers  the  BSA  by  providing  a 
number  of  regular  expressions  that  must  match  the  e-mail’s  headers  and/or  body. 
For  each  of  these  triggers,  the  user  also  specifies  the  BSA’s  appropriate  reaction. 

A  mail  filter  is  a  list  of  these  (trigger,  response)  pairs.  User’s  can  create  multiple 
mail  filters  which  are  examined  by  the  BSA  when  there  is  incoming  e-mail.  The  BSA 
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can  also  batch  new  messages,  waiting  until  a  certain  minimum  number  (specifiable  by 
the  user)  arrive  before  running  the  mail  filters.  Currently,  SodaBot  does  not  give  the 
user  particularly  good  control  over  incoming  message  volume,  i.e.,  how  many  windows 
the  BSA  is  allowed  to  pop-up  on  the  user’s  screen.  While  the  announcement  of  new 
messages  can  be  delayed,  there  is  no  mechanism  for  prioritizing  a  group  of  incoming 
requests  and  perhaps  eliminating  those  of  lesser  importance  or  allowing  the  user  to 
select  among  them.  We  hope  to  add  these  capabilities  shortly. 

SodaBotL  mail  filter  primitives: 

Mail  filter:  (No  arguments) 

Declares  that  the  following  expressions  constitute  a  mail  filter.  All  subsequent 
SodaBotL  expressions  up  to  the  next  Agent  or  Mail  filter  statement  comprise  the 
body  of  the  mail  filter. 


Received  Mail  [{header  1:  /reg-expl/;  header2:  /reg-exp2;  ...}  expressions] 

If  mail  arrives  where  each  header  matches  the  corresponding  regular  expression, 
execute  the  given  SodaBotL  expressions.  A  received  mail  statement  with  an  empty 
header-regular  expression  list  gets  triggered  on  every  message. 

Sample  expressions: 

Mail  filter: 

Received  mail  {from:  /fax  notifier/;  to:  /$me/;  subject:  /arrival/}: 

Display  “An  incoming  fax  has  arrived.”; 

Received  mail  {from:  /$me/:}: 

Save  {append}  /Mail /outgoing”  Smessage; 

4.2.5  Writing  an  Agent 

SodaBot  application  agents  are  divided  into  four  sections:  (See  figure  3-1.) 


1.  Global  declarations 
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2.  The  main  agent 

3.  Agent  requests 

4.  Agent  subroutines 

This  section  presents  the  syntactic  specification  of  each  of  these  sections.  A  model 
for  approaching  application  agent  design  was  discussed  in  section  4.1. 


Global  declarations 

Global  declarations  are  variable  assignments  which  can  be  referenced  by  all  agents 
requests  and  subroutines.  They  are  included  in  all  distributions  of  the  agent. 


Agent  Name: 

[Required  input  { String-1 :  *  type  Tl 

String-2:  *  type-2  . . .  }] 

[SodaBotL  expressions] 

The  Agent  declaration  begins  the  definition  of  the  named  agent.  All  subsequent 
SodaBotL  expressions  up  to  the  next  Agent  or  Mail  filter  statement  comprise  the 
body  of  the  entire  agent. 

The  Required  input  specifies  the  format  of  the  input  which  must  be  supplied  to 
the  agent.  The  SodaBotL  expressions  are  run  by  the  agent  when  it  is  invoked. 


Required  input  { String-1 :  HypeA 

String-2:  *type-2  . . .  }] 
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The  Required  input  specification  is  a  template  for  describing  the  format  of  the 
structured  e-mail  message  which  invokes  the  agent.  Each  line  in  the  specification 
must  match  a  corresponding  line  in  the  message  such  that  the  ordering  is  preserved. 
The  type  expression  *typeJ  can  be  any  of  the  types  shown  on  page  73  or  an  arbitrary 
regular  expression. 

For  example,  we  again  note  the  correspondence  between  the  e-mail  from  page  35 
and  the  authorize  agent  in  section  4.1: 


To:  authorize@ai.mit.edu 

as  input  to  Agent  authorize: 

Required  input  { 

Person  1:  las 

person  1:  *username 

Person  1:  brooks 

person2:  *username 

pathname:  ~ mhcoen/tr.ps 

pathname:  *pathname} 

Request  Name:  {group [s]  groupl,  . . .  } 

[Required  input  {String-1:  Hype  A 

String-2:  *type-2  . . .  }] 

[SodaBotL  expressions } 

A  Request  declaration  begins  the  definition  of  the  named  request.  All  subsequent 
expressions  up  to  the  next  Request  or  Subroutine  or  until  the  end  of  the  agent’s 
program  comprise  the  body  of  the  request.  Requests  can  specify  Required  input  to 
allow  people  to  invoke  them  directly.  However,  assuming  it  was  invoked  by  a  BSA, 
a  request’s  body  can  directly  reference  variables  substituted  into  the  e-mail  when  it 
was  sent.  For  example,  note  the  correspondence  between: 

Agent  A:  contacting  (in  Agent  A) 

Sperson  =  Susername;  Request  hello:  {group  main} 

Contact  Agent  <A;  hello  {user:  mhcoen}  Display  “You  received 
“Hi,  I  am  Sperson.”;  greetings  from  Sperson.”; 


CHAPTER  4.  WRITING  SODABOT  AGENTS 


51 


Subroutine  Name  {gToup[s]  group 1,  . . .  }{ 

[SodaBotL  expressions ]} 

A  Subroutine  declaration  defines  the  named  subroutine.  The  body  of  the  sub¬ 
routine  is  contained  within  the  indicated  brackets.  Subroutines  have  no  explicit 
arguments;  however,  they  can  directly  access  the  variables  defined  in  the  requests 
which  invoke  them.  Note  that  subroutines  are  invoked  only  by  requests,  not  other  by 
subroutines.  They  are  called  by  prefacing  their  name  with  an 

4.2.6  SodaBotL  Primitives 

Contact  Agent  <Agentname;  Requestname>  {userjs]:  userl,  user2,  . . .  }  [ string J; 

Agents  issue  requests  to  one  another  via  Contact  Agent.  The  users  field  specifies 
whose  BSAs  receive  the  given  request.  The  optional  string  specifies  input  for  the 
particular  request  being  issued.  Any  variables  referenced  in  this  string  can  be  directly 
referenced  in  the  receiving  agent.  If  a  receiving  BSA  doesn’t  have  either  the  specified 
agent  or  the  particular  request  section  of  that  agent,  it  issues  use  Contact  Agent  to 
get  the  software  from  the  RequestAgent  of  whoever  initiated  this  interaction. 

Currently,  agents  contacts  are  only  relayed  via  e-mail.  We  are  beginning  work  on 
a  TCP/IP  connection  for  the  BSA  as  an  alternate  and  hopefully  faster  inter-agent 
communication  medium. 

Sample  expression: 

Contact  Agent  <007;  setname>  {user:  $  secret }  “James  Bond”; 


Load  filename  variable; 

Loads  the  contents  of  filename  into  the  named  variable. 

Sample  expressions: 

Load  $filename  $contents; 

Load  “/home/c2/mhcoen/. schedule”  Sschedule; 
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Mail  [to]  address:  string 

Mail  simply  sends  the  specified  string  the  given  address. 

Sample  expressions: 

Load  “"/letter”  Sletter; 

Mail  to  mhcoenai.mit.edu:  Sletter; 

Mail  to  $user:  “Your  toast  has  popped  up.\n”; 


Reply  with  string 

Replies  to  current  mail  message  with  given  string. 
Sample  expression: 

Reply  with  “My  final  offer  is  $USDollars.\n”; 


Save  [{append}]  filename  string; 

Saves  (or  appends)  the  specified  string  into  the  named  file. 

Sample  expressions: 

Save  “/usr/tmp/ current”  “Sfrom,  Ssubject”; 

Save  {append}  “/usr /gam  es/XCh  ess / $  hook,  op  enings  ”  “It  was  a  dark 
and  stormy  night. \n”; 


_ GUI  Primitives - 

Display  [{choices(cstringJ,  cstring.2);  no  delay;  timeout  in  interval;  for  interval}} 
string; 

Display  creates  a  window  containing  the  specified  string  on  the  user’s  current 
display.  Choices  allows  the  user  to  select  possible  responses  from  stacked  rows  of 
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“radio  buttons.”  The  BSA  puts  the  agent  to  sleep  until  she  has  made  her  selections 
unless  no  delay  is  specified.  The  SodaBotL  choice  array  is  indexed  over  all  specified 
options,  e.g.  cstring.l  -  cstring_i;  after  the  user  makes  her  selections,  an  element  in  the 
array  is  true  if  the  user  selected  the  corresponding  button  in  the  displayed  window. 
The  timeout  (and  equivalently  for)  specification  force  the  window  created  by  this 
command  to  disappear  after  the  given  interval  and  wake  the  agent  up.  Multiple  new 
windows  appear  in  a  staggered,  overlapping  layout  to  reduce  screen  clutter. 

Display  (and  other  GUI-specific  primitives)  have  emacs-style  “hooks”  which  can 
be  invoked  before  the  command  is  executed.  These  hooks  are  simply  appropriatety 
named  subroutines,  e.g.  Display Jiook,  which  are  intended  to  allow  the  GUI  access 
to  be  redirected  to  another  communication  medium. 

Sample  expression: 

Display  {  choices(yes ,  no);  for  one  hour}  “Mail  from  Lynn! 

Do  you  want  to  read  it  now?”; 


Get  Response  [{prompt  =  string;  no  delay;  timeout  in  interval;  for  interval }]  string; 

Get  Response  displays  creates  a  window  containing  the  specified  string  on  the 
user’s  current  display.  This  window  also  contains  a  mini-editor  that  allows  the  user 
to  enter  an  arbitrary  textual  response  to  the  specified  prompt.  This  response  is 
available  to  the  SodaBotL  program  in  the  Sresponse  variable. 

Sample  expression: 

Get  response  { prompt  =  “What  is  your  answer?”} 

“ $quiz-quesiion 


Query  [{type  =  reg-exp;  prompt  =  string;  no  delay;  timeout  in  interval;  for  interval }] 
j  string; 
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Query  displays  creates  a  window  containing  the  specified  string  on  the  user’s 
current  display.  It  allows  the  user  to  enter  a  one-line  response  which  much  match  the 
given  reg-exp  in  response  to  the  given  prompt. 

Sample  expression: 

Query  {prompt  =  “When  you  are  you  free?”;  type  =  time} 

Sschedule; 

4.3  The  Benefit 

SodaBotL  contributes  more  complete  solutions  to  two  of  the  three  problems  outlined 
above  with  software  agent  construction. 

1.  Software  agents  can  be  technically  challenging  to  write  in  traditional  program¬ 
ming  languages  and  operating  systems: 

•  SodaBotL  offers  high-level  primitives  and  control-structures  designed 
around  human-level  descriptions  of  agent  activity.  It  allows  users  to  easily 
create  automatically-distributed  software  agents  while  ignoring  low-level 
implementational  details. 

•  Because  SodaBotL  agent  programs  can  be  much  shorter  and  higher-level 
than  their  counterparts  in  more  traditional  systems,  they  are  easier  to 
debug  and  maintain. 

2.  People  may  be  uncomfortable  with  the  amount  of  responsibility  given  to  an 
unknown  (and  possibly  buggy)  agent. 

•  Users  can  inspect  SodaBotL  programs  for  security  threats  more  easily  than 
would  be  possible  with  agent  programs  written  in  other  programming  lan¬ 
guages,  because:  (1)  the  level  of  discourse  is  so  much  higher;  and  (2)  the 
programs  are  smaller. 

> 
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Chapter  5 


Software  Agents 


The  thesis  has  so  far  presented  a  specific  view  of  what  software  agents  are  and  how 
they  should  be  used.  However,  software  agents  come  in  many  flavors,  and  they  differ 
widely  in  terms  of  specialization,  usefulness,  and  theoretical  motivation.  This  chapter 
discusses  related  work  in  the  field  and  then  outlines  the  common  ties  that  link  even 
vastly  dissimilar  agent  implementations.  We  simultaneously  discuss  how  SodaBot 
relates  to  and  differs  from  other  work  in  the  field. 

Section  5.3  presents  our  motivation  for  designing  the  SodaBot  system  based  on 
experience  described  in  [Kautz  et  al .,  1994] 

5.1  What’s  an  Agent? 

There  is  simply  no  set  of  necessary  or  sufficient  criteria  for  determining  whether  some 
program  is  indeed  a  software  agent.  The  “definition”  varies  widely,  as  do  approaches 
to  building  agents.  However,  we  can  look  for  some  general  agent  characteristics  by 
examining  some  typical  (and  not  necessarily  mutually  exclusive)  approaches. 

We  note  here  that  no  other  software  agent  system  (of  any  flavor)  that  we  know 
of  has  an  automated  distribution  mechanism  like  SodaBot’s.  In  fact,  personal  com¬ 
munication  with  several  of  the  researchers  below  indicates  that  this  currently  poses 
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some  difficultly,  because  few  people  outside  of  their  research  groups  can  make  use  of 
their  agents. 

5.1.1  Software  agents  are  on-line  pseudo-people 

Software  agents  are  ontologically  grounded  in  their  role  in  the  agent  community. 
Agents  have  beliefs,  commitments,  obligations,  intentions,  and  perhaps  even  confu¬ 
sion,  stubbornness,  etc.  Exactly  what  these  agents  do  with  all  their  commitments, 
obligations,  intentions,  etc,  has  not  necessarily  been  made  particularly  clear,  but 
what’s  supposed  to  be  important  is  that  we  have  a  motivated  vocabulary  for  de¬ 
scribing  coordinated  agent  interaction,  e.g.  Agentl  sent  Agent2  e-mail  because  it  felt 
“obligated,”  or  perhaps  Agentl  crashed  the  network  because  it  was  “confused. 

[Shoham,  1993]  has  defined  an  formal  language  for  describing  agents’  “mental 
states”  in  terms  of  epistemic  logic.  He  also  presents  a  corresponding  agent  program¬ 
ming  language  called  AGENT-0  ([Torrance  and  Viola,  1991])  which  is  semantically 
grounded  in  this  mental  state  language.  AGENT-0  very  much  resembles  Prolog,  but 
it  has  primitives  which  are  well-suited  for  communication  of  obligations,  beliefs,  and 
capabilities  between  agents. 

Whereas  SodaBot  is  intended  for  assisting  with  practical,  on-line  tasks,  AGENT-0 
is  suited  for  researching  the  interaction  of  coordinated  cognitively-based  agents,  i.e. 
agents  that  think,  but  don’t  do  much  else.  It  would  seem  that  neither  system  would  be 
particularly  adept  at  handling  the  job  of  the  other.  His  approach  does  not  necessarily 
conflict  with  our  own.  In  fact,  it  would  be  very  interesting  to  try  combining  aspects 
of  both  systems  by  providing  BSAs  with  some  type  of  formal  intentional  state. 

We  note  that  there  is  much  other  theoretical  research  into  agent  cognition,  such 
as  [Doyle  et  a/.,  1991].  Again,  it  would  be  very  interesting  to  ground  this  work  by 
implementing  it  in  a  realized  system. 
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5.1.2  Software  agents  are  a  testbed  for  other  realms  in  Core 

AL 

Software  agents  are  the  new  universal  research  tool  for  AI.  Because  expert  systems 
and  robots  are  leaving  the  limelight,  software  agents  (and  the  people  who  research 
them)  should  enjoy  their  moment  in  the  sun. 

[Etzioni,  1993]  argues  that  software  agents  are  an  ideal  “foundation  for  core 
AI  research.”  While  we  agree  with  this  conclusion,  we  do  not  accept  the  argu¬ 
ments  he  uses  to  reach  it  (see  [Coen,  1994]).  Regardless,  Etzioni  et  aFs  work  on 
Unix  “softbots”  ([Etzioni  et  al.,  1992a,  Etzioni  et  al.,  1993,  Etzioni  and  Segal,  1992, 
Etzioni  et  al .,  1994])  provides  a  very  interesting  foundation  for  exploring  many  cen¬ 
tral  issues  in  traditional  core  AI,  particularly  in  planning.  There  are  many  differ¬ 
ences  between  this  work  and  our  own.  Softbots  are  intended  for  much  more  system- 
administration  oriented  applications  than  are  SodaBots;  therefore,  the  softbot  level 
of  discourse  is  in  terms  of  (low-level)  Unix  primitives.  Softbot  agents  do  not  seem 
to  interact  with  anything  other  than  their  owners,  and  thus,  their  capabilities  do  not 
extend  to  inter-agent  communication.1  Finally,  the  softbot  system  does  not  seem  to 
have  any  provisions  for  assisting  with  distribution  of  softbot  agents  or  their  UWL 
plans. 

The  Darpa  Knowledge  Sharing  Effort  ([Neches  et  al ,  1991])  has  encouraged 
much  agent-based  research  into  knowledge  representation  and  communication  lan¬ 
guages.  This  effort  has  led  to  the  design  of  an  agent  communication  language 
(ACL)  intended  as  a  universal  medium  for  agent  discourse.  Genesereth  et  al 
([Genesereth  and  Singh,  1994,  Genesereth  and  Ketchpel,  1994])  present  a  “federa¬ 
tion”  agent  architecture  that  employs  this  ACL,  and  [Genesereth  1994]  discusses  these 
agents  obtaining  arbitrary  software  programs  from  other  agents  by  advertising  their 
required  specifications  written  in  ACL. 

1We  don’t  consider  even  sophisticated  interaction  with  disk  drives  and  printers  to  be 
communication. 
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It  is  worth  noting  that  work  on  ACL  has  yet  not  been  completed,  so  agent  sys¬ 
tems  which  communicate  in  ACL  do  not  yet  exist.  We  also  remain  highly  skeptical 
of  this  ACL’s  ontological  sufficiency  and  soundness.  Furthermore,  agents  would  have 
to  “know”  a  program  existed  before  they  could  advertise  for  it;  this  type  of  distri¬ 
bution  does  not  address  how  novel  programs  are  spread  among  networked  agents. 
Finally,  this  work  makes  no  mention  of  the  practical  consequences  its  type  of  distri¬ 
bution  would  entail,  nor  does  it  discuss  the  required  effort  to  realize  the  described 
hypothetical  agents. 

The  work  of  [Vere  and  Bickmore,  1990]  is  quite  unusual.  Their  “basic  agent”  has 
a  remarkably  wide  core  AI  foundation,  drawing  on  a  broader  range  of  research  areas 
than  any  other  system  with  which  we  are  familiar.  However,  their  domain  is  so  narrow 
and  their  application  so  involved  that  it  bears  little  resemblance  to  any  current  work 
in  software  agents. 

5.1.3  Software  agents  are  intelligent  on-line  assistants 

Software  agents  are  artificial  secretaries  which  are  the  electronic  counterpart  of  their 
real-world  namesakes.  This  is  not  to  say  that  anyone  looks  forward  to  the  prompt 
delivery  of  simulated  coffee  each  morning!  Rather,  these  personal  assistants  are  de¬ 
signed  for  tasks  such  as:  filtering  e-mail,  scanning  NetNews,  providing  appointment 
reminders,  etc.2  Given  the  complexity  of  on-line  environments  and  huge  volume  of 
information  flowing  across  the  Internet,  this  type  of  agent  looks  quite  attractive. 

Interface  agents  ([Maes,  1994,  Sheth,  1994])  are  a  special  class  of  on-line  assis¬ 
tants  which  are  designed  to  simply  user-interaction  with  particular  pre-existing  ap¬ 
plications.  These  agents  are  designed  to  learn  and  predict  users’  behaviors  and  pref¬ 
erences.  SodaBots  have  little  in  common  with  interface  agents,  because  interface 
agents  are  each  highly  elaborate,  custom-crafted  programs  designed  for  very  specific 

2One  rather  extreme  and  slightly  dismaying  example  of  an  on-line  assistant  might  be  the  H.A.L. 
9000  in  2001:  A  Space  Odyssey. 
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applications.  Also,  SodaBot  does  not  have  built-in  capabilities  for  learning  user  be¬ 
havior  and  preferences.  Providing  these  would  be  an  interesting  direction  for  future 
development  of  the  SodaBot  system. 

For  example,  Sheth  provides  an  interactive  information  retrieval  system  for  UseNet 
NetNews  articles.  It  is  designed  to  autonomously  select  those  articles  whose  content 
would  interest  the  user  according  to  some  complex  metric  involving  the  user’s  pre¬ 
vious  selections.  Sheth’s  work  is  similar  in  spirit  to  much  of  the  activity  regarding 
knowbots™  ([Kahn  and  Cerf,  1988,  Waldrop,  1990]),  which  has  generally  fallen  out¬ 
side  of  the  realm  of  mainstream  AI  research,  although  there  are  some  exceptions,  e.g. 
[Knoblock  and  Arens,  1994].  Knowbots  (knowledge  robots)  are  intended  roughly  as 
librarians  for  enormous  digital  data-libraries.  They  are  not  general  purpose  but  are 
highly  elaborate,  specific  creations.  Thus,  these  too  have  little  if  anything  in  common 
with  SodaBots. 

5.1.4  Software  agents  are  negotiators 

Groups  of  software  agents  can  make  decisions  or  form  coalitions.  If  a  group  of  people 
with  complex  time-constraints  need  to  arrange  a  meeting,  software  agents  can  do  it  for 
them  without  requiring  that  a  person  bother  with  the  intricate  constraint  balancing 
inherent  in  meeting-scheduling  (and  perhaps  without  anyone’s  feelings  getting  hurt). 

In  fact,  meeting  scheduling  is  the  most  popular  software  agent  negotiation 
application.  [Kozierok,  1993,  Maes  and  Kozierok,  1993]  schedules  group  meetings, 
[Kautz  et  al ,  1994]  schedules  meetings  between  individuals,  and  [Dent  et  al. ,  1992] 
does  both  (and  more).  The  backbone  of  all  of  these  systems  could  be  implemented  in 
SodaBot.  However,  the  actual  scheduling  processes  would  require  external  applica¬ 
tions.  For  example,  Kautz  et  ah’s  VisitorBot  requires  use  of  CPlex  —  a  sophisticated 
integer  programming  package  —  which  could  be  accessed  through  the  SodaBot  system 
command.3 


3CPlex  actually  requires  a  very  expensive  machine-specific  license.  However,  we  note  (without 


CHAPTER  5.  SOFTWARE  AGENTS 


60 


There  has  also  been  much  theoretical  work  on  abstract  agent  negotiation  protocols, 
as  in  [Zlotkin  and  Roesnschein,  1994,  Rosenschein,  1993].  As  we  pointed  out  earlier 
with  reference  to  the  work  of  Doyle,  it  would  be  very  interesting  to  ground  this 
theoretical  work  in  negotiation  by  implementing  it  in  a  realized  system. 

5.1.5  Other  Points  of  View 

[Stein,  1994]  has  suggested  that  “agency”  (i.e.,  the  property  of  being  an  agent)  is 
determined  by  an  observer’s  intentional  stance;  what  a  person  views  as  an  agent  is 
an  agent.  While  this  may  well  be  a  tenable  philosophical  position,  it  is  not  clear 
what  benefit  it  provides.  Rather,  in  term  of  directing  research  efforts,  particularly 
with  the  growing  popularity  of  “agents,”  it  might  be  preferable  to  narrow  the  scope 
of  the  term.  Even  in  research  communities  this  designation  is  perhaps  being  abused. 
Work  such  as  [Lansky,  1994]  was  once  called  an  expert  system.  It  was  quite  surprising 
to  hear  such  a  classic  example  of  that  paradigm  being  presented  at  the  AAAI  1994 
Spring  Symposium  on  Software  Agents. 

The  final  system  we  discuss  is  Telescript  ([Wayner,  1994]).  Although  few  details 
of  this  proprietary  system  have  been  disclosed,  enough  information  has  been  released 
to  permit  a  tentative  comparison.  Telescript  is  a  very  sophisticated  computational 
environment  in  which  machine-independent  programs  move  freely  around  a  network. 
Telescript  programs  are  interpreted,  and  interpreters  exist  for  all  standard  platforms. 
Essentially,  in  terms  of  portability,  it  is  the  algorithmic  equivalent  of  “postscript.” 

High  Telescript,  the  system’s  programming  language,  is  reportedly  very  similar 
to  Smalltalk  and  Modula-3.  Thus,  it  does  not  provide  the  right  level  of  abstraction 
for  writing  agent  applications.  Furthermore,  Teiescript  programs  have  fixed  mean¬ 
ings,  i.e.  primitives  are  not  interpreted  with  respect  to  their  context.  However,  it 
would  seem  that  Telescript  might  be  an  ideal  system  for  reimplementing  SodaBot. 


advocating)  that  by  setting  up  a  BSA  on  the  machine  on  which  CPiex  has  been  installed,  it  is  trivial 
to  allow  anyone,  anywhere,  to  access  CPiex  via  a  simple  SodaBot  application  agent. 
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Regardless,  we  look  forward  to  seeing  what  comes  out  of  this  very  promising  endeavor. 
Telescript  seems  like  a  step  in  the  right  direction. 


5.2  Agency  Defined 

Clearly,  there  is  an  enormous  variety  in  what  people  deem  a  software  agent,  and  it 
is  somewhat  difficult  to  tell  whether  this  is  good  or  bad  for  the  field.  Nonetheless, 
having  many  enthusiastic  researchers  working  on  their  various  “agents”  is  probably 
to  everyone’s  benefit,  so  we  refrain  from  complaining  too  loudly. 

However,  we  favor  the  following  as  a  set  of  minimum  criteria  for  establishing  a 
program’s  “agency:” 

1.  Software  agents  engage  in  dialogs;  we  don’t  issue  commands  to  agents,  rather 
we  have  conversations  with  them.  The  communication  patterns  among  agents 
can  be  quite  complicated. 

2.  Software  agents  are  autonomous  and  intelligent;  they  respond  to  complex  stimuli 
with  sophisticated  (and  appropriate)  behaviors. 

3.  Software  agents  must  be  robust.  Because  they  are  autonomous  and  presum¬ 
ably  doing  something  important,  agents  must  be  able  to  respond  to  unexpected 
changes  in  their  computation  world. 

4.  Software  agents  are  generally  not  time  invariant  —  they  have  memory  and 
change  what  they  do  over  time.  Agents  can  employ  formal  machine  learning 
techniques,  or  they  can  more  casually  collect  data  while  they  operate.  Per¬ 
sonal  assistants  can  learn  patterns  in  their  owners’  behavior,  and  more  gener¬ 
ally,  agents  can  spontaneously  react  to  particular  events  in  their  computational 
world. 

5.  Software  agents  are  typically  distributed  across  a  network,  so  their  behavior  can 
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have  both  local  and  global  effects.  Abstraction  barriers  can  become  confused  if 
an  agent  is  responsible  for  too  many  non-local  events. 

5.3  SodaBot’s  Motivation 

The  SodaBot  system  was  heavily  influenced  by  my  participation  in  developing  the 
VisitorBot  ([Kautz  et  a/.,  1994])  in  the  AT&T  Bell  Laboratories’  AI  Principles  Re¬ 
search  Group.4 

5.3.1  The  VisitorBot 

The  VisitorBot  is  a  software  agent  that  schedules  meetings  with  a  visiting  researcher 
(who  is  presumably  also  giving  a  talk).  The  VisitorBot  distributes  the  talk’s  abstract 
and  accepts  requests  for  meetings  with  the  speaker.  It  then  distributes  schedule- 
outlines  which  are  filled  out  by  those  interested  in  reserving  a  time  slot.  Finally,  after 
receiving  submitted  time  constraints  from  users,  the  agent  generates  (and  distributes) 
a  schedule  of  meetings  with  the  visitor. 

The  history  behind  the  development  of  this  agent  is  revealing.  The  version  de¬ 
scribed  in  [Kautz  et  al. ,  1994]  was  begun  at  AT&T  Bell  Labs  while  I  was  a  summer 
student  there.  However,  due  to  numerous  technical  difficulties,  this  agent  was  not 
yet  completed  by  the  time  I  returned  to  MIT  at  the  end  of  the  summer.5  Therefore, 
I  ported  the  agent  to  the  MIT  AI  Lab  in  order  to  finish  working  on  it.  Interfacing 
the  agent  to  the  AI  Lab’s  mailer  involved  nontrivial  effort,  and  after  completing  it 
here,  installing  and  debugging  the  agent  at  Bell  Labs  remotely  from  MIT  required  a 
ridiculous  amount  of  time.  (This  was  primarily  due  to  Bell  Lab’s  network  “firewall.”) 
While  writing  the  VisitorBot  (among  other  agents)6,  it  became  clear  that  get- 

4 1  worked  at  Bell  Labs  from  the  the  middle  of  May  through  the  first  week  of  September  during 
1993. 

5Steven  Ketchpei  actually  implemented  an  earlier,  complete  version  of  the  VisitorBot  on  top  of 
a  simple  mail-reading  agent  developed  by  Henry  Kautz. 

6I  wrote  several  other  software  agents  at  Bell  Labs  over  the  summer.  Most  notable  is  the  RTgXBot 
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ting  an  agent  to  run  at  a  particular  location  required  a  large  amount  of  site-specific 
information.  Additionally,  an  agent  which  centrally  controlled  all  aspects  of  user- 
interaction  was  prone  to  failure  in  a  networked  environment.  (For  example,  it  is 
not  possible  to  open  X-Windows  across  a  firewall.)  Essentially,  there  were  no  clean 
abstraction  barriers  for  writing  agent  software. 

The  development  of  personal  agents  in  [Kautz  et  al,  1994]  was  a  first  step  towards 
establishing  some  minimum  level  of  distinction  between  local  and  non-local  agent 
activity.  For  example,  the  VisitorBot  could  tell  a  user’s  personal  agent  to  open  a 
window  on  the  user’s  display  rather  than  doing  so  itself.  However,  both  the  VisitorBot 
and  its  involved  personal  agents  are  very  much  ad  hoc ,  non-generalizable  creations. 
The  personal  agent  in  [Kautz  et  al.,  1994]  is  hard-coded  and  custom  tailored  to  the 
VisitorBot,  i.e.  a  hypothetical  PaperReviewBot  would  require  that  users  obtain  a 
different  personal  agent  to  interact  with  it.  According  to  this  approach,  every  time  a 
new  agent  is  written,  each  user  must  install  the  appropriate  personal  agent  to  permit 
interaction  with  it. 

SodaBot  was  my  reaction  to  the  effort  required  for  writing  and  installing  the 
VisitorBot.  Although  we  found  that  it  was  generally  very  easy  to  state  succinctly 
the  desired  agent  behavior  in  English,  it  was  quite  another  thing  to  formulate  this  in 
Perl  and  C.  This  distinction  differentiates  between  SodaBot  and  efforts  in  the  field  of 
automated  programming.  Loosely  speaking,,  the  shortest  specification  of  a  program 
is  generally  the  program  itself;  however,  given  the  highly  specialized  domain  in  which 
software  agents  function  (at  least  in  SodaBot),  it  is  usually  quite  easy  to  give  a  short 
high-level  specification  of  an  agent’s  desired  behavior.  SodaBot  takes  advantage  of 
this  by  allowing  an  agent  creator  to  provide  merely  this  high-level  specification.  The 
system  essentially  handles  all  the  effort  involved  in  actually  realizing  the  specified 
agent. 

which  allowed  me  to  edit  my  SM  thesis  proposal  at  Bell  Labs  and  process  it  remotely  at  MIT.  It 
notified  me  of  any  errors  encountered  during  text  processing  at  MIT,  displayed  the  final  results  on 
my  Bell  Labs’  workstation,  etc. 
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We  did  not  address  in  [Kautz  ei  al,  1994]  how  a  new  agent  is  released  to  the 
world.  The  VisitorBot  was  a  collection,  of  random  C  and  Perl  files  which  had  to 
be  installed  and  configured  by  a  skilled  human  being.  The  difficulties  inherent  in 
encouraging  use  of  new  agents  are  thus  enormous.  Not  only  would  a  new  user  need  to 
be  convinced  that  the  files  are  safe  to  install  and  to  use,  but  she  would  additionally 
have  to  be  willing  to  trust  the  system  could,  for  example,  handle  her  e-mail  properly. 
Finally,  installing  and  running  the  VisitorBot  also  sometimes  required  root  access, 
which  generally  would  prevent  the  average  user  from  installing  it  herself. 

How  to  distribute  new  agents  was  the  subject  of  much  discussion  over  the  summer. 
The  approach  in  SodaBot  was  motivated  by  a  discussion  of  distributed  agent  planning 
at  a  Bell  Lab’s  Bot  meeting,  where  Ron  Brachman  suggested  that  planning  agents 
could  e-mail  STRIPS  operators  to  each  other.  I  was  quite  taken  with  this  idea  and  it 
eventually  found  its  way  into  SodaBot  (where  agents  instead  send  SodaBot  programs). 


Chapter  6 


Conclusions 


This  chapter  evaluates  the  SodaBot  system;  we  discuss  it  strengths,  weaknesses,  and 
future  work. 


6.1  SodaBot ’s  Report  Card 

We  could  evaluate  the  SodaBot  system  by  the  following  criteria: 

1.  It  solves  the  problems  listed  in  section  1.2. 

2.  Naive  users  enjoyed  interacting  with  it. 

3.  We  learned  something  building  it. 

However,  only  the  first  and  third  are  currently  capable  of  being  assessed,  because 
we  did  not  have  genuinely  naive  users  test  SodaBot.  Nonetheless,  we  examine  each 
of  the  three  criteria  in  turn  and  discuss  how  it  is  addressed  by  various  components  of 
the  SodaBot  system. 


It  solves  the  problems  listed  in  section  1.2: 

1.  Software  agents  can  be  technically  challenging  to  write  in  traditional  program¬ 
ming  languages  and  operating  systems: 
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•  The  BSA  provides  the  right  foundation  for  software  agent  creation.  It 
removes  system  specific  aspects  of  agent  creation  from  the  domain  of  the 
agent  programmer. 

•  SodaBotL  offers  a  level  of  discourse  appropriate  for  the  types  of  on-line 
activities  in  which  agents  engage.  The  high  level  primitives  in  SodaBotL 
allow  agents  to  be  written  more  quickly  and  in  less  space. 

For  example,  we  can  approximately  implement  the  “VisitorBot”  system 
described  in  [Kautz  et  al.,  1994]  in  several  pages  of  SodaBotL  code.1  The 
VisitorBot  implementation  described  there  is  well  over  50  pages  of  Perl 
and  C  code. 

2.  Software  agents  are  difficult  to  distribute  because  they  may  have  site-specific 
dependencies;  for  the  same  reason,  they  can  be  difficult  to  install. 

•  The  BSA  disconnects  application  agents  from  the  specific  computational 
environment  in  which  they  run.  Agent  programs  no  longer  need  to  be 
“hard-coded”  with  site-specific  information.  The  problem  of  configuring 
many  software  agents  is  reduced  to  the  problem  of  configuring  a  single 
agent,  i.e.,  the  BSA. 

•  Agents  in  SodaBot  distribute  themselves  over  the  Internet  and/or  local 
area  networks.  Although  there  is  currently  only  a  Unix  platform  for  Soda¬ 
Bot,  this  distribution  can  theoretically  be  across  operating  systems.  Sim¬ 
ply  put,  the  acquisition  of  new  agents  in  SodaBot  does  not  require  that 
the  user  do  anything. 

3.  People  may  be  uncomfortable  with  the  amount  of  responsibility  given  to  an 
unknown  (and  possibly  buggy)  agent. 

1In  terms  of  features,  the  two  scheduling  agents  are  not  strictly  comparable  yet.  Kautz  et  aV s 
looks  better.  Ours  is  more  robust. 
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•  The  BSA  allows  the  user  to  gradually  establish  confidence  in  its  behavior 
and  to  selectively  disable  and  enable  access  to  specific  system  resources.  It 
provides  a  stable  agent-framework  over  which  the  user  can  exert  ultimate 
control. 

The  system  as  a  whole  has  seen  four  months  of  use,  testing,  and  debug¬ 
ging,  and  its  longest  continuous  operation  without  restarting  has  lasted 
approximately  one  week.  It  has  been  reliable  handling  e-mail,  i.e.,  it  has 
not  lost  messages,  and  it  has  had  low  system  overhead. 

•  Users  can  inspect  SodaBotL  programs  for  security  threats  more  easily  than 
would  be  possible  with  agent  programs  written  in  other  programming  lan¬ 
guages,  because:  (1)  the  level  of  discourse  is  so  much  higher;  and  (2)  the 
programs  are  smaller. 

We  feel  SodaBot  successfully  presents  solutions  to  the  specified  problems.  How¬ 
ever,  most  of  our  time  has  been  spent  developing  the  system,  not  using  it.  We  have 
built  many  “toy  agents”  but  very  few  large-scale  ones.  Therefore,  we  can’t  (yet)  claim 
a  flood  of  agent  development  has  resulted  from  the  SodaBot  system.  Hopefully,  when 
the  system  is  “bullet-proofed”  and  released  for  general  use,  more  agent  applications 
will  be  forthcoming. 

Finally,  we  acknowledge  that  evaluating  the  SodaBot  system  is  not  a  necessarily 
objective  process.  We  have  received  the  critique  “[the  authorize  agent  in  section  4.1] 
would  be  very  easy  to  implement  in  very  few  lines  of  [non-SodaBotL]  code.”  Even 
though  this  agent  is  a  quite  simplified  version  of  what  an  “end  product”  would  require, 
we  disagree  and  suggest  that  those  who  are  skeptical  of  our  position  actually  go  ahead 
and  implement  the  agent  in  “very  few  lines.”2 


2Some  things  to  consider  include  handling:  (1)  network  downage;  (2)  e-mail  lossage;  (3)  user 
I/O;  (4)  distributing  the  agent  so  that  people  can  use  it;  etc. 


CHAPTER  6.  CONCLUSIONS 


68 


Naive  users  enjoyed  interacting  with  it. 

SodaBot  is  not  intended  to  be  a  “Unix  wizards  only”  tool.  A  major  consideration 
while  designing  it  was  to  make  it  as  user-friendly  as  possible.  For  example,  the 
compiler  gives  quite  instructive  error  messages;  it  points  out  explicitly  the  offending 
statement  and  suggests  what  might  be  the  problem  and  how  to  fix  it.  However,  we 
can’t  say  any  genuinely  naive  users  have  used  it,  so  the  assessment  of  this  criterion 
will  have  to  wait. 

There  are  some  definite  aspects  of  the  system  that  need  improvement,  particularly 
with  respect  to  mail  filters.  For  example,  users  will  almost  certainly  insist  on  some 
way  of  prioritizing  mail  filter  firing  so  they  don’t  get  flooded  by  window’s  popping  up 
on  their  screen  after  a  long  absence.  This  does  not  constitute  a  major  addition,  and 
implementing  user  demands  can  only  increase  the  value  of  the  system. 


We  learned  something  while  building  it. 

Certainly,  a  fair  amount  (perhaps  too  much)  of  Unix,  X-windows,  C  language,  etc. 
knowledge  was  acquired  building  SodaBot.  It  provided  ample  opportunity  to  learn 
about  the  many  obscure  aspects  of  building  large  “real-world”  systems. 

However,  perhaps  the  best  indication  that  we  learned  something  is  that  we  are 
immediately  setting  out  to  rewrite  it.  We  want  to  make  SodaBot  more  user-extensible: 
she  should  be  able  to  declare  new  SodaBotL  primitives,  enhance  the  GUT,  and  easily 
hook  the  BSA  up  to  arbitrary  system  components,  e.g.  a  speech  synthesizer. 

We  do  not  plan  on  distributing  the  current  SodaBot  implementation  outside  of 
the  MIT  AI  Lab.  We  will  continue  rewriting  it,  playing  with  it,  and  introducing 
it  to  the  local  community.  We  feel  it  was  a  very  good  first  step  towards  making  a 
general  purpose  software  agent  construction  system.  We  very  much  look  forward  to 
completing  the  next  release  and  seeing  what  people  end  up  doing  with  it. 
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6.2  Closing  Summary 

This  thesis  has  presented  SodaBot,  a  software  agent  user-environment  and  construc¬ 
tion  system.  The  basic  software  agent  was  introduced  as  a  foundation  for  construct¬ 
ing  SodaBot  application  agents.  We  then  presented  SodaBotL  —  the  software  agent 
programming  language  —  whose  primitives  are  designed  around  human-level  descrip¬ 
tions  of  agent  activity.  Via  this  programming  language,  users  can  easily  implement 
a  wide-range  of  typical  software  agent  applications.  Along  the  way  we  also  discussed 
how  people  go  about  writing  application  agents  and  how  SodaBot  automatically  dis¬ 
tributes  them. 


Appendix  A 

Details  of  the  Current 
Implementation 


The  primary  difference  between  the  current  SodaBotL  syntax  and  the  one  presented  in 
the  paper  is  in  the  structural  division  of  agent  programs.  In  both  versions,  application 
agents  are  stored  in  unique  directories  in  “"/.sodabot/AgentsSrc/”  However,  the 
current  version  requires  that  each  group  of  an  agent  be  stored  in  a  seperate  sub¬ 
directory;  thus,  no  single  file  contains  an  entire  agent  having  2  or  more  (non-trivial) 
groups.  Each  group  is  acutally  treated  as  a  unique  application  agent. 

Also,  in  the  current  implementation: 

1.  All  numbers  must  be  inside  quotes. 

2.  The  types  listed  in  the  agent  input  specification  on  page  73  do  not  exist. 

3.  Order  is  not  preserved  for  required  inputs. 

4.  The  “SodaBot-Parser:”  header  does  not  work  for  multiline  strings. 

5.  The  Smessage  variable  is  not  preserved  if  the  agent  is  placed  in  one  of  the  three 
databases. 

6.  Subroutines  are  identical  to  requests.  An  agent  simply  directs  a  request  to  its 
host  BSA  to  call  a  subroutine,  so  variables  must  be  passed  explicitly. 

7.  The  semi-colon  and  bracketing  syntax  are  slightly  different. 
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Appendix  B 

SodaBotL  BNF  Specification 

Functional  Declarations: _ 

<Program>  <Mail  filter>  [<Program>]  ]  <Agent>  [<Program>] 

< Mail  filter >  ::=  Mail  filter:  [<Declaration>*]  <Mail  description>* 

-  <Mail  description>  ::=  Received  Mail  [{<Mail  specification^]: 

<Statements>* 

<Agent>  Agent  < Agent  name>; 

[<Input>] 

<Statements>* 

<Agent  requests>* 

<Subroutine>* 

<Agent  request>  ::=  Request  <Request  string>:  [{  group  <string>  }]  <Statements>* 
<Subroutine>  Subroutine  <Sub  name>([<Arg  list>]):  [{group  <string>}] 

{<Statements>*} 

<Declaration>  ::=  Library  <Library  name>  |  <Declaration> 
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Statements: 

<Statement> 

<  Assignment 
<System> 
<Save> 

<Load> 

<  Reply  > 

<Mail> 

<Contact  agent 

<Sub  call> 

<If> 


<Assignment>  j  <System>  |  <Save>  j  <Load>  j  <Reply>  | 
<Mail>  |  <Contact  agent>  |  <Sub  call>  |  <If>  |  <GUI  call> 
<Variable>  =  <String  value>; 

::=  System  <String  value>; 

::=  Save  [{Append}]  <;FiIename>  <String  value>; 

::=  Load  <Filename>  <Variable>; 

Reply  with  <String  value>; 

Mail  to  <Address>;  <String  value>; 

::=  Contact  agent  <<Agent  name>;<Request  string>> 

{users:  <Address  list}  [<String  value>]; 

::=  $<Sub  name>([<Arg  List>]); 

::=  If  (<Condition>)  {  <Statement>  } 

[elsif  (<Condition>)  {<Statement>}]* 

[ else  {<Statement>}] 


GUI  Statements: 
<GUI  call> 

<Display> 

<Get  response> 
<Query> 


<Display>  |  <Get  response>  |  <Query> 
[{<Display  options>*}]  <String  value>; 
[{< Query  options>*}]  <String  value>; 

[{< Query  options>*}]  <String  value>; 


<Condition>  <Boolean> 

<String  value>  eq  <String  value> 

<String  value>  neq  <String  value> 

::=  <Reg  exp>  in  <String  value>  | 

<String  vaiue>  <Reg  exp> 

<Reg  exp>  nin  <String  value>  | 

<String  value>  !~  <Reg  exp> 

::=  (<Condition>)  or  (<Condition>) 

|  (<Condition>)  ||  (<Condition>) 

(<Condition>)  and  (<Condition>) 

|  (<Condition>)  &&  (<Condition>) 

APPENDIX  B.  SODABOTL  BNF  SPECIFICATION 
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Data  Types: 


<String  value>  : 

:=  <String>  j  <Variable> 

<String>  : 

:=  <Multiline  string>  j  <Simple  string> 

<Variable>  : 

:=  $<Simple  string> 

<Filename>  : 

:=  [/]  <Simple  string>  [/]  [<Filename>]  |  <Variable> 

<Sub  name>  : 

:=  <Simple  string> 

<Agent  name>  : 

:=  <Simple  string> 

<  Library  name>  : 

:=  <Simple  string> 

<Arg  list>  : 

:=  <String  value>  [,  <Arg  list>] 

<Multline  string>  : 

:=  <Rich  string>  \n  [<Multiline  string>] 

<Rich  string>  : 

:=  All  characters  except  \n 

<Simple  string>  : 

:=  [a-z,  A-Z,  OS,  .j* 

<Reg  exp>  : 

:=  See  [Wall  and  Schwartz,  1990,  p25] . 

Mail  Filter  Specification: _ 

<Field>:  /<Regexp>/  [;<Mail  Specification^ 
to  |  cc  |  bcc  |  from  |  sender  |  reply-to  | 
return-receipt-to  |  errors-to  j  date  ] 
return-header  j  message-id  |  subject  |  status  | 
newsgroups  |  followup-to 

Agent  Input  Specification: _ 

<Input>  ::=  Required  input  {<Input  spec>} 

<Input  spec>  ::=  <Rich  string>:  <Input  type> 

<Input  type>  ::=  <Rich  string>  |  *name  j  *username  |  *filename  | 
*date  |  *time  |  *address  \  *host  \  *number 


<Mail  specification> 
<Field> 
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